From vagabon.xyz@gmail.com Tue Nov 1 08:33:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Nov 2005 08:33:54 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.196]:15250 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133494AbVKAIdg convert rfc822-to-8bit (ORCPT ); Tue, 1 Nov 2005 08:33:36 +0000 Received: by zproxy.gmail.com with SMTP id j2so970709nzf for ; Tue, 01 Nov 2005 00:34:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FBjxjaOmeJHqS0BdUh/jH+MMRqHfl6tER2i+S8EDjKGkKYoWyCk34J/RQEC0YS67/8EqhYkOhOY3QFRJ/u5Wv5Ndp5ybjVWwNb5TMEakQJldmkx/V90xoFCnN6eAzkDCCYf3mE8QwEvXOLK2Dp/8sEfFFFgL6DisM95Hrgaf4X4= Received: by 10.37.22.77 with SMTP id z77mr4239674nzi; Tue, 01 Nov 2005 00:34:11 -0800 (PST) Received: by 10.36.48.2 with HTTP; Tue, 1 Nov 2005 00:34:11 -0800 (PST) Message-ID: Date: Tue, 1 Nov 2005 09:34:11 +0100 From: Franck To: "Kevin D. Kissell" Subject: Re: [RFC] Add 4KSx support (try 2) Cc: linux-mips@linux-mips.org, Ralf Baechle In-Reply-To: <4366584C.8080503@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <4365DF22.8060004@mips.com> <4366584C.8080503@mips.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/10/31, Kevin D. Kissell : > Franck wrote: > > >>There are places, for example arch/mips/mm/cache.c, but > >>also some of the other makefiles, where you're using your > >>new config flags to drive things where the standard > >>CONFIG_CPU_MIPS32 (which I guess has now fragmented into > >>CONFIG_CPU_MIPS32_R1 and CONFIG_CPU_MIPS32_R2, which would > >>apply to the Sc and Sd respectively) would do the right thing > >>while creating fewer source file mods. > >> > > > > > > That's correct but CONFIG_CPU_MIPS32_Rx seems to be a fallback case. > > Don't other cpu use their own flags whereas they could just use > > CONFIG_CPU_MIPS32_Rx flag instead ? > > I think that those other CPUs aren't, strictly speaking, > MIPS32-compliant CPUs in one respect or another, so they > end up picking up MIPS32 kernel behavior "a la carte". > The 4KS family is a strict superset. > If so, that makes sense. Ralf, should I modify the patch to use CONFIG_CPU_MIPS32_Rx flags whenever it's possible as suggest Kevin ? Thanks -- Franck From milang@tal.org Tue Nov 1 11:26:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Nov 2005 11:26:45 +0000 (GMT) Received: from gw02.mail.saunalahti.fi ([195.197.172.116]:21646 "EHLO gw02.mail.saunalahti.fi") by ftp.linux-mips.org with ESMTP id S8133769AbVKAL0Y (ORCPT ); Tue, 1 Nov 2005 11:26:24 +0000 Received: from tori.tal.org (tori.tal.org [195.16.220.82]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 62CA2D5D9E for ; Tue, 1 Nov 2005 13:26:57 +0200 (EET) Date: Tue, 1 Nov 2005 13:28:48 +0200 (EET) From: Kaj-Michael Lang To: linux-mips@linux-mips.org Subject: Working XZ console Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: milang@tal.org Precedence: bulk X-list: linux-mips Hi This is the first ever e-mail written using local XZ console on a Indigo2! The driver is 99% working, I've tested running links, pine and nano and all display correctly. The only bug that I know of is in normal console mode, the last line won't get cleared when scrolling. The code is mess right now, but I'll post it after I've cleaned it up. If anyone with a XZ would like to try it, download the ip22 kernel from http://home.tal.org/~milang/o2/kernels/ Please post success/failure stories. -- Kaj-Michael Lang From satheshbabu.edara@analog.com Wed Nov 2 15:35:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 15:36:11 +0000 (GMT) Received: from nwd2mail3.analog.com ([137.71.25.52]:16569 "EHLO nwd2mail3.analog.com") by ftp.linux-mips.org with ESMTP id S8133803AbVKBPfw (ORCPT ); Wed, 2 Nov 2005 15:35:52 +0000 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail3.analog.com (8.12.10/8.12.10) with ESMTP id jA2FaU2N020540 for ; Wed, 2 Nov 2005 10:36:30 -0500 Received: from lilac.hdcindia.analog.com ([10.121.13.31]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id KAA29292 for ; Wed, 2 Nov 2005 10:36:27 -0500 (EST) Received: from SEdaraL01 (sedara-l01.ad.analog.com [10.82.242.18]) by lilac.hdcindia.analog.com (8.12.10+Sun/8.12.10) with ESMTP id jA2FUTrn015102 for ; Wed, 2 Nov 2005 21:00:33 +0530 (IST) Message-Id: <200511021530.jA2FUTrn015102@lilac.hdcindia.analog.com> From: "Sathesh Babu Edara" To: Subject: Linux-2.6.12 code base for linux-mips Date: Wed, 2 Nov 2005 21:06:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXccO7ASOw3odwVTnGYrDo/jS4S6QDS2e9A In-Reply-To: <20051029101445.GC2935@linux-mips.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.49 on 137.71.25.52 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: satheshbabu.edara@analog.com Precedence: bulk X-list: linux-mips Hi, - I would like to know the code base for linux-2.6.12 (linux_2_6_12 tag) in the CVS repository is same as the one in the git repository archive(linux-2.6.12). - I am new to GIT.In order to checkout linux-2.6.12 tag from git repository I followed the commands given in the http://www.linux-mips.org/wiki/Git web site - It is hanging while cloning the repository using the below command # git clone rsync://ftp.linux-mips.org/git/linux.git linux.git - Then i used http:// instead of rsync:// in the above command and it is working fine. In the "Status of CVS to GIT conversion " section, there is no information on linux-2.6.12 tag/branch.If I want to checkout linux-2.6.12 tag from GIT repository what command I should use after cloning the git repository. Thanks in advance. Regards, Sathesh From anemo@mba.ocn.ne.jp Wed Nov 2 16:01:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 16:02:03 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:23267 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133805AbVKBQBi (ORCPT ); Wed, 2 Nov 2005 16:01:38 +0000 Received: from localhost (p4242-ipad211funabasi.chiba.ocn.ne.jp [58.91.160.242]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4076FAAA6; Thu, 3 Nov 2005 01:02:16 +0900 (JST) Date: Thu, 03 Nov 2005 01:01:15 +0900 (JST) Message-Id: <20051103.010115.07642880.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] use rtc_lock to protect RTC operations From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9403 X-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 Many RTC routines are not protected each other. There are potential race, for example, ntp-update and /dev/rtc. This patch fixes them using rtc_lock. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/ddb5xxx/common/rtc_ds1386.c b/arch/mips/ddb5xxx/common/rtc_ds1386.c --- a/arch/mips/ddb5xxx/common/rtc_ds1386.c +++ b/arch/mips/ddb5xxx/common/rtc_ds1386.c @@ -41,7 +41,9 @@ rtc_ds1386_get_time(void) u8 byte; u8 temp; unsigned int year, month, day, hour, minute, second; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* let us freeze external registers */ byte = READ_RTC(0xB); byte &= 0x3f; @@ -60,6 +62,7 @@ rtc_ds1386_get_time(void) /* enable time transfer */ byte |= 0x80; WRITE_RTC(0xB, byte); + spin_unlock_irqrestore(&rtc_lock, flags); /* calc hour */ if (temp & 0x40) { @@ -81,7 +84,9 @@ rtc_ds1386_set_time(unsigned long t) u8 byte; u8 temp; u8 year, month, day, hour, minute, second; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* let us freeze external registers */ byte = READ_RTC(0xB); byte &= 0x3f; @@ -133,6 +138,7 @@ rtc_ds1386_set_time(unsigned long t) if (second != READ_RTC(0x1)) { WRITE_RTC(0x1, second); } + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/dec/time.c b/arch/mips/dec/time.c --- a/arch/mips/dec/time.c +++ b/arch/mips/dec/time.c @@ -37,10 +37,25 @@ #include +/* + * Returns true if a clock update is in progress + */ +static inline unsigned char dec_rtc_is_updating(void) +{ + unsigned char uip; + unsigned long flags; + + spin_lock_irqsave(&rtc_lock, flags); + uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP); + spin_unlock_irqrestore(&rtc_lock, flags); + return uip; +} + static unsigned long dec_rtc_get_time(void) { unsigned int year, mon, day, hour, min, sec, real_year; int i; + unsigned long flags; /* The Linux interpretation of the DS1287 clock register contents: * When the Update-In-Progress (UIP) flag goes from 1 to 0, the @@ -49,11 +64,12 @@ static unsigned long dec_rtc_get_time(vo */ /* read RTC exactly on falling edge of update flag */ for (i = 0; i < 1000000; i++) /* may take up to 1 second... */ - if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) + if (dec_rtc_is_updating()) break; for (i = 0; i < 1000000; i++) /* must try at least 2.228 ms */ - if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)) + if (!dec_rtc_is_updating()) break; + spin_lock_irqsave(&rtc_lock, flags); /* Isn't this overkill? UIP above should guarantee consistency */ do { sec = CMOS_READ(RTC_SECONDS); @@ -77,6 +93,7 @@ static unsigned long dec_rtc_get_time(vo * of unused BBU RAM locations. */ real_year = CMOS_READ(RTC_DEC_YEAR); + spin_unlock_irqrestore(&rtc_lock, flags); year += real_year - 72 + 2000; return mktime(year, mon, day, hour, min, sec); @@ -95,6 +112,8 @@ static int dec_rtc_set_mmss(unsigned lon int real_seconds, real_minutes, cmos_minutes; unsigned char save_control, save_freq_select; + /* irq are locally disabled here */ + spin_lock(&rtc_lock); /* tell the clock it's being set */ save_control = CMOS_READ(RTC_CONTROL); CMOS_WRITE((save_control | RTC_SET), RTC_CONTROL); @@ -141,6 +160,7 @@ static int dec_rtc_set_mmss(unsigned lon */ CMOS_WRITE(save_control, RTC_CONTROL); CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); + spin_unlock(&rtc_lock); return retval; } diff --git a/arch/mips/jmr3927/common/rtc_ds1742.c b/arch/mips/jmr3927/common/rtc_ds1742.c --- a/arch/mips/jmr3927/common/rtc_ds1742.c +++ b/arch/mips/jmr3927/common/rtc_ds1742.c @@ -57,7 +57,9 @@ rtc_ds1742_get_time(void) { unsigned int year, month, day, hour, minute, second; unsigned int century; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); CMOS_WRITE(RTC_READ, RTC_CONTROL); second = BCD2BIN(CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK); minute = BCD2BIN(CMOS_READ(RTC_MINUTES)); @@ -67,6 +69,7 @@ rtc_ds1742_get_time(void) year = BCD2BIN(CMOS_READ(RTC_YEAR)); century = BCD2BIN(CMOS_READ(RTC_CENTURY) & RTC_CENTURY_MASK); CMOS_WRITE(0, RTC_CONTROL); + spin_unlock_irqrestore(&rtc_lock, flags); year += century * 100; @@ -81,7 +84,9 @@ rtc_ds1742_set_time(unsigned long t) u8 year, month, day, hour, minute, second; u8 cmos_year, cmos_month, cmos_day, cmos_hour, cmos_minute, cmos_second; int cmos_century; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); CMOS_WRITE(RTC_READ, RTC_CONTROL); cmos_second = (u8)(CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK); cmos_minute = (u8)CMOS_READ(RTC_MINUTES); @@ -139,6 +144,7 @@ rtc_ds1742_set_time(unsigned long t) /* RTC_CENTURY and RTC_CONTROL share same address... */ CMOS_WRITE(cmos_century, RTC_CONTROL); + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/lasat/ds1603.c b/arch/mips/lasat/ds1603.c --- a/arch/mips/lasat/ds1603.c +++ b/arch/mips/lasat/ds1603.c @@ -8,6 +8,7 @@ #include #include #include +#include #include "ds1603.h" @@ -138,19 +139,27 @@ static void rtc_end_op(void) unsigned long ds1603_read(void) { unsigned long word; + unsigned long flags; + + spin_lock_irqsave(&rtc_lock, flags); rtc_init_op(); rtc_write_byte(READ_TIME_CMD); word = rtc_read_word(); rtc_end_op(); + spin_unlock_irqrestore(&rtc_lock, flags); return word; } int ds1603_set(unsigned long time) { + unsigned long flags; + + spin_lock_irqsave(&rtc_lock, flags); rtc_init_op(); rtc_write_byte(SET_TIME_CMD); rtc_write_word(time); rtc_end_op(); + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/momentum/jaguar_atx/setup.c b/arch/mips/momentum/jaguar_atx/setup.c --- a/arch/mips/momentum/jaguar_atx/setup.c +++ b/arch/mips/momentum/jaguar_atx/setup.c @@ -149,7 +149,9 @@ arch_initcall(per_cpu_mappings); unsigned long m48t37y_get_time(void) { unsigned int year, month, day, hour, min, sec; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* stop the update */ rtc_base[0x7ff8] = 0x40; @@ -166,6 +168,7 @@ unsigned long m48t37y_get_time(void) /* start the update */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return mktime(year, month, day, hour, min, sec); } @@ -173,11 +176,13 @@ unsigned long m48t37y_get_time(void) int m48t37y_set_time(unsigned long sec) { struct rtc_time tm; + unsigned long flags; /* convert to a more useful format -- note months count from 0 */ to_tm(sec, &tm); tm.tm_mon += 1; + spin_lock_irqsave(&rtc_lock, flags); /* enable writing */ rtc_base[0x7ff8] = 0x80; @@ -201,6 +206,7 @@ int m48t37y_set_time(unsigned long sec) /* disable writing */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/momentum/ocelot_3/setup.c b/arch/mips/momentum/ocelot_3/setup.c --- a/arch/mips/momentum/ocelot_3/setup.c +++ b/arch/mips/momentum/ocelot_3/setup.c @@ -135,7 +135,9 @@ void setup_wired_tlb_entries(void) unsigned long m48t37y_get_time(void) { unsigned int year, month, day, hour, min, sec; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* stop the update */ rtc_base[0x7ff8] = 0x40; @@ -152,6 +154,7 @@ unsigned long m48t37y_get_time(void) /* start the update */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return mktime(year, month, day, hour, min, sec); } @@ -159,11 +162,13 @@ unsigned long m48t37y_get_time(void) int m48t37y_set_time(unsigned long sec) { struct rtc_time tm; + unsigned long flags; /* convert to a more useful format -- note months count from 0 */ to_tm(sec, &tm); tm.tm_mon += 1; + spin_lock_irqsave(&rtc_lock, flags); /* enable writing */ rtc_base[0x7ff8] = 0x80; @@ -187,6 +192,7 @@ int m48t37y_set_time(unsigned long sec) /* disable writing */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/momentum/ocelot_c/setup.c b/arch/mips/momentum/ocelot_c/setup.c --- a/arch/mips/momentum/ocelot_c/setup.c +++ b/arch/mips/momentum/ocelot_c/setup.c @@ -140,7 +140,9 @@ unsigned long m48t37y_get_time(void) unsigned char* rtc_base = (unsigned char*)0xfc800000; #endif unsigned int year, month, day, hour, min, sec; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* stop the update */ rtc_base[0x7ff8] = 0x40; @@ -157,6 +159,7 @@ unsigned long m48t37y_get_time(void) /* start the update */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return mktime(year, month, day, hour, min, sec); } @@ -169,11 +172,13 @@ int m48t37y_set_time(unsigned long sec) unsigned char* rtc_base = (unsigned char*)0xfc800000; #endif struct rtc_time tm; + unsigned long flags; /* convert to a more useful format -- note months count from 0 */ to_tm(sec, &tm); tm.tm_mon += 1; + spin_lock_irqsave(&rtc_lock, flags); /* enable writing */ rtc_base[0x7ff8] = 0x80; @@ -197,6 +202,7 @@ int m48t37y_set_time(unsigned long sec) /* disable writing */ rtc_base[0x7ff8] = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/pmc-sierra/yosemite/setup.c b/arch/mips/pmc-sierra/yosemite/setup.c --- a/arch/mips/pmc-sierra/yosemite/setup.c +++ b/arch/mips/pmc-sierra/yosemite/setup.c @@ -73,7 +73,9 @@ void __init bus_error_init(void) unsigned long m48t37y_get_time(void) { unsigned int year, month, day, hour, min, sec; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); /* Stop the update to the time */ m48t37_base->control = 0x40; @@ -88,6 +90,7 @@ unsigned long m48t37y_get_time(void) /* Start the update to the time again */ m48t37_base->control = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return mktime(year, month, day, hour, min, sec); } @@ -95,11 +98,13 @@ unsigned long m48t37y_get_time(void) int m48t37y_set_time(unsigned long sec) { struct rtc_time tm; + unsigned long flags; /* convert to a more useful format -- note months count from 0 */ to_tm(sec, &tm); tm.tm_mon += 1; + spin_lock_irqsave(&rtc_lock, flags); /* enable writing */ m48t37_base->control = 0x80; @@ -123,6 +128,7 @@ int m48t37y_set_time(unsigned long sec) /* disable writing */ m48t37_base->control = 0x00; + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/sgi-ip22/ip22-time.c b/arch/mips/sgi-ip22/ip22-time.c --- a/arch/mips/sgi-ip22/ip22-time.c +++ b/arch/mips/sgi-ip22/ip22-time.c @@ -35,7 +35,9 @@ static unsigned long indy_rtc_get_time(v { unsigned int yrs, mon, day, hrs, min, sec; unsigned int save_control; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); save_control = hpc3c0->rtcregs[RTC_CMD] & 0xff; hpc3c0->rtcregs[RTC_CMD] = save_control | RTC_TE; @@ -47,6 +49,7 @@ static unsigned long indy_rtc_get_time(v yrs = BCD2BIN(hpc3c0->rtcregs[RTC_YEAR] & 0xff); hpc3c0->rtcregs[RTC_CMD] = save_control; + spin_unlock_irqrestore(&rtc_lock, flags); if (yrs < 45) yrs += 30; @@ -60,6 +63,7 @@ static int indy_rtc_set_time(unsigned lo { struct rtc_time tm; unsigned int save_control; + unsigned long flags; to_tm(tim, &tm); @@ -68,6 +72,7 @@ static int indy_rtc_set_time(unsigned lo if (tm.tm_year >= 100) tm.tm_year -= 100; + spin_lock_irqsave(&rtc_lock, flags); save_control = hpc3c0->rtcregs[RTC_CMD] & 0xff; hpc3c0->rtcregs[RTC_CMD] = save_control | RTC_TE; @@ -80,6 +85,7 @@ static int indy_rtc_set_time(unsigned lo hpc3c0->rtcregs[RTC_HUNDREDTH_SECOND] = 0; hpc3c0->rtcregs[RTC_CMD] = save_control; + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } diff --git a/arch/mips/sibyte/swarm/rtc_m41t81.c b/arch/mips/sibyte/swarm/rtc_m41t81.c --- a/arch/mips/sibyte/swarm/rtc_m41t81.c +++ b/arch/mips/sibyte/swarm/rtc_m41t81.c @@ -144,6 +144,7 @@ static int m41t81_write(uint8_t addr, in int m41t81_set_time(unsigned long t) { struct rtc_time tm; + unsigned long flags; to_tm(t, &tm); @@ -153,6 +154,7 @@ int m41t81_set_time(unsigned long t) * believe we should finish writing min within a second. */ + spin_lock_irqsave(&rtc_lock, flags); tm.tm_sec = BIN2BCD(tm.tm_sec); m41t81_write(M41T81REG_SC, tm.tm_sec); @@ -180,6 +182,7 @@ int m41t81_set_time(unsigned long t) tm.tm_year %= 100; tm.tm_year = BIN2BCD(tm.tm_year); m41t81_write(M41T81REG_YR, tm.tm_year); + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } @@ -187,19 +190,23 @@ int m41t81_set_time(unsigned long t) unsigned long m41t81_get_time(void) { unsigned int year, mon, day, hour, min, sec; + unsigned long flags; /* * min is valid if two reads of sec are the same. */ for (;;) { + spin_lock_irqsave(&rtc_lock, flags); sec = m41t81_read(M41T81REG_SC); min = m41t81_read(M41T81REG_MN); if (sec == m41t81_read(M41T81REG_SC)) break; + spin_unlock_irqrestore(&rtc_lock, flags); } hour = m41t81_read(M41T81REG_HR) & 0x3f; day = m41t81_read(M41T81REG_DT); mon = m41t81_read(M41T81REG_MO); year = m41t81_read(M41T81REG_YR); + spin_unlock_irqrestore(&rtc_lock, flags); sec = BCD2BIN(sec); min = BCD2BIN(min); diff --git a/arch/mips/sibyte/swarm/rtc_xicor1241.c b/arch/mips/sibyte/swarm/rtc_xicor1241.c --- a/arch/mips/sibyte/swarm/rtc_xicor1241.c +++ b/arch/mips/sibyte/swarm/rtc_xicor1241.c @@ -113,9 +113,11 @@ int xicor_set_time(unsigned long t) { struct rtc_time tm; int tmp; + unsigned long flags; to_tm(t, &tm); + spin_lock_irqsave(&rtc_lock, flags); /* unlock writes to the CCR */ xicor_write(X1241REG_SR, X1241REG_SR_WEL); xicor_write(X1241REG_SR, X1241REG_SR_WEL | X1241REG_SR_RWEL); @@ -160,6 +162,7 @@ int xicor_set_time(unsigned long t) xicor_write(X1241REG_HR, tmp); xicor_write(X1241REG_SR, 0); + spin_unlock_irqrestore(&rtc_lock, flags); return 0; } @@ -167,7 +170,9 @@ int xicor_set_time(unsigned long t) unsigned long xicor_get_time(void) { unsigned int year, mon, day, hour, min, sec, y2k; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); sec = xicor_read(X1241REG_SC); min = xicor_read(X1241REG_MN); hour = xicor_read(X1241REG_HR); @@ -183,6 +188,7 @@ unsigned long xicor_get_time(void) mon = xicor_read(X1241REG_MO); year = xicor_read(X1241REG_YR); y2k = xicor_read(X1241REG_Y2K); + spin_unlock_irqrestore(&rtc_lock, flags); sec = BCD2BIN(sec); min = BCD2BIN(min); diff --git a/include/asm-mips/mc146818-time.h b/include/asm-mips/mc146818-time.h --- a/include/asm-mips/mc146818-time.h +++ b/include/asm-mips/mc146818-time.h @@ -33,7 +33,9 @@ static inline int mc146818_set_rtc_mmss( int real_seconds, real_minutes, cmos_minutes; unsigned char save_control, save_freq_select; int retval = 0; + unsigned long flags; + spin_lock_irqsave(&rtc_lock, flags); save_control = CMOS_READ(RTC_CONTROL); /* tell the clock it's being set */ CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL); @@ -79,14 +81,30 @@ static inline int mc146818_set_rtc_mmss( */ CMOS_WRITE(save_control, RTC_CONTROL); CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT); + spin_unlock_irqrestore(&rtc_lock, flags); return retval; } +/* + * Returns true if a clock update is in progress + */ +static inline unsigned char rtc_is_updating(void) +{ + unsigned char uip; + unsigned long flags; + + spin_lock_irqsave(&rtc_lock, flags); + uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP); + spin_unlock_irqrestore(&rtc_lock, flags); + return uip; +} + static inline unsigned long mc146818_get_cmos_time(void) { unsigned int year, mon, day, hour, min, sec; int i; + unsigned long flags; /* * The Linux interpretation of the CMOS clock register contents: @@ -97,12 +115,13 @@ static inline unsigned long mc146818_get /* read RTC exactly on falling edge of update flag */ for (i = 0 ; i < 1000000 ; i++) /* may take up to 1 second... */ - if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) + if (rtc_is_updating()) break; for (i = 0 ; i < 1000000 ; i++) /* must try at least 2.228 ms */ - if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)) + if (!rtc_is_updating()) break; + spin_lock_irqsave(&rtc_lock, flags); do { /* Isn't this overkill ? UIP above should guarantee consistency */ sec = CMOS_READ(RTC_SECONDS); min = CMOS_READ(RTC_MINUTES); @@ -120,6 +139,7 @@ static inline unsigned long mc146818_get BCD_TO_BIN(mon); BCD_TO_BIN(year); } + spin_unlock_irqrestore(&rtc_lock, flags); year = mc146818_decode_year(year); return mktime(year, mon, day, hour, min, sec); diff --git a/include/asm-mips/time.h b/include/asm-mips/time.h --- a/include/asm-mips/time.h +++ b/include/asm-mips/time.h @@ -20,6 +20,9 @@ #include #include #include +#include + +extern spinlock_t rtc_lock; /* * RTC ops. By default, they point to no-RTC functions. From anemo@mba.ocn.ne.jp Wed Nov 2 16:03:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 16:03:22 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:49915 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133803AbVKBQDC (ORCPT ); Wed, 2 Nov 2005 16:03:02 +0000 Received: from localhost (p4242-ipad211funabasi.chiba.ocn.ne.jp [58.91.160.242]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D0701891E; Thu, 3 Nov 2005 01:03:41 +0900 (JST) Date: Thu, 03 Nov 2005 01:02:40 +0900 (JST) Message-Id: <20051103.010240.41630907.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] remove mips_rtc_lock From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9404 X-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 The mips_rtc_lock is no longer needed because RTC operations should be protected already by other mechanism. (rtc_lock, local_irq_save, etc.) Also, locking whole rtc_get_time/rtc_set_time should be avoided while some RTC routines might take very long time (a few seconds). Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/rtc.h b/include/asm-mips/rtc.h --- a/include/asm-mips/rtc.h +++ b/include/asm-mips/rtc.h @@ -14,7 +14,6 @@ #ifdef __KERNEL__ -#include #include #include @@ -29,17 +28,13 @@ #define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */ #define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */ -static DEFINE_SPINLOCK(mips_rtc_lock); - static inline unsigned int get_rtc_time(struct rtc_time *time) { unsigned long nowtime; - spin_lock(&mips_rtc_lock); nowtime = rtc_get_time(); to_tm(nowtime, time); time->tm_year -= 1900; - spin_unlock(&mips_rtc_lock); return RTC_24H; } @@ -49,12 +44,10 @@ static inline int set_rtc_time(struct rt unsigned long nowtime; int ret; - spin_lock(&mips_rtc_lock); nowtime = mktime(time->tm_year+1900, time->tm_mon+1, time->tm_mday, time->tm_hour, time->tm_min, time->tm_sec); ret = rtc_set_time(nowtime); - spin_unlock(&mips_rtc_lock); return ret; } From ralf@linux-mips.org Wed Nov 2 19:25:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 19:26:19 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:20504 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133821AbVKBTZw (ORCPT ); Wed, 2 Nov 2005 19:25:52 +0000 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 jA2JQPwA005928; Wed, 2 Nov 2005 19:26:25 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA2JQO6F005927; Wed, 2 Nov 2005 19:26:24 GMT Date: Wed, 2 Nov 2005 19:26:24 +0000 From: Ralf Baechle To: Sathesh Babu Edara Cc: linux-mips@linux-mips.org Subject: Re: Linux-2.6.12 code base for linux-mips Message-ID: <20051102192624.GA3725@linux-mips.org> References: <20051029101445.GC2935@linux-mips.org> <200511021530.jA2FUTrn015102@lilac.hdcindia.analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511021530.jA2FUTrn015102@lilac.hdcindia.analog.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9405 X-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 On Wed, Nov 02, 2005 at 09:06:16PM +0530, Sathesh Babu Edara wrote: > - I would like to know the code base for linux-2.6.12 (linux_2_6_12 tag) > in the CVS repository is same as the one in the git repository > archive(linux-2.6.12). It should be; the tags in the git archive were automatically generated, not converted fromt he CVS archive. > - I am new to GIT.In order to checkout linux-2.6.12 tag from git > repository I followed the commands given in the > http://www.linux-mips.org/wiki/Git web site > > > - It is hanging while cloning the repository using the below command > # git clone rsync://ftp.linux-mips.org/git/linux.git linux.git > - Then i used http:// instead of rsync:// in the above command and it is > working fine. We told you before - you're behind a firewall and can't use rsync. Unless you have an argument with your firewall admin and those are usually a rather stuborn kind of character when it comes to that kind of changes :) > In the "Status of CVS to GIT conversion " section, there is no information > on linux-2.6.12 tag/branch.If I want to checkout linux-2.6.12 tag from GIT > repository what command I should use after cloning the git repository. I certainly won't list each of the hundreds of individual tags on that page; no point in that. ANyway, after the clone finished, do: git-read-tree -m $(cat .git/refs/tags/linux-2.6.12) git-checkout-index -f -a -u -q Git developers didn't make that too easy; the git-checkout command doesn't accept a tag as it's argument, so git-checkout linux-2.6.12 doesn't work. Ralf From adi@hexapodia.org Wed Nov 2 19:44:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 19:44:31 +0000 (GMT) Received: from straum.hexapodia.org ([64.81.70.185]:1825 "EHLO straum.hexapodia.org") by ftp.linux-mips.org with ESMTP id S8133822AbVKBToL (ORCPT ); Wed, 2 Nov 2005 19:44:11 +0000 Received: by straum.hexapodia.org (Postfix, from userid 22448) id E8DAB283; Wed, 2 Nov 2005 11:44:53 -0800 (PST) Date: Wed, 2 Nov 2005 11:44:53 -0800 From: Andy Isaacson To: Pavel Machek Cc: Richard Purdie , LKML , Russell King , Greg KH , linux-mips@linux-mips.org Subject: Re: [RFC] The driver model, I2C and gpio provision on Sharp SL-C1000 (Akita) Message-ID: <20051102194453.GF26542@hexapodia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051029190819.GB657@openzaurus.ucw.cz> User-Agent: Mutt/1.4.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adi@hexapodia.org Precedence: bulk X-list: linux-mips On Sat, Oct 29, 2005 at 09:08:19PM +0200, Pavel Machek wrote: > > I2C drivers appear relatively late in the boot procedure and changing > > that isn't practical. I therefore ended up writing akita-ioexp which > > It seems that making i2c init early is only sane choice. I realize PC people > will hate it... but apart from that, why is it impractical? FWIW, I have also run into this "I need I2C early in boot, but it's not inited until late" on SiByte (arch/mips/sibyte/{sb1250,bcm1480}/setup.c). For the time being in the linux-mips tree we simply have two drivers talking to the I2C interface - sibyte/swarm/rtc_* and i2c-sibyte.c, and they are currently lacking even any trivial locking. We haven't seen any problems yet but that's due to limited exercise - the default config doesn't hook up any drivers for the other chips on I2C. How do other arches that have I2C RTCs deal with this problem? Or is there something wrong with how arch/mips/kernel/time.c:time_init deals with the rtc? > > There is a fundamental problem with the lack of a proper gpio interface > > in Linux. Every driver does something different with them (be it pxa > > specific gpios, SCOOP gpios, those on a IO expander, those on a video > > chip (w100fb springs to mind) to name just the Zaurus specific ones. > > Yup. GPIOs are not problem on i386, so noone solved this one :-(. I would also be overjoyed to have a GPIO infrastructure to plug into. (And I would say "GPIOs are not used on PCs"; I am confident the Geode driving the seat-back TV on this Song flight has GPIOs...) -andy From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Wed Nov 2 22:52:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Nov 2005 22:52:45 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([212.18.232.186]:33548 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S8133830AbVKBWwY (ORCPT ); Wed, 2 Nov 2005 22:52:24 +0000 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.52) id 1EXRTX-0005p6-O9; Wed, 02 Nov 2005 22:53:00 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.52) id 1EXRTV-0008G6-PP; Wed, 02 Nov 2005 22:52:57 +0000 Date: Wed, 2 Nov 2005 22:52:57 +0000 From: Russell King To: Andy Isaacson Cc: Pavel Machek , Richard Purdie , LKML , Greg KH , linux-mips@linux-mips.org Subject: Re: [RFC] The driver model, I2C and gpio provision on Sharp SL-C1000 (Akita) Message-ID: <20051102225257.GE4778@flint.arm.linux.org.uk> Mail-Followup-To: Andy Isaacson , Pavel Machek , Richard Purdie , LKML , Greg KH , linux-mips@linux-mips.org References: <20051029190819.GB657@openzaurus.ucw.cz> <20051102194453.GF26542@hexapodia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051102194453.GF26542@hexapodia.org> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmk+lkml@arm.linux.org.uk Precedence: bulk X-list: linux-mips On Wed, Nov 02, 2005 at 11:44:53AM -0800, Andy Isaacson wrote: > On Sat, Oct 29, 2005 at 09:08:19PM +0200, Pavel Machek wrote: > > > I2C drivers appear relatively late in the boot procedure and changing > > > that isn't practical. I therefore ended up writing akita-ioexp which > > > > It seems that making i2c init early is only sane choice. I realize PC people > > will hate it... but apart from that, why is it impractical? > > FWIW, I have also run into this "I need I2C early in boot, but it's not > inited until late" on SiByte (arch/mips/sibyte/{sb1250,bcm1480}/setup.c). > For the time being in the linux-mips tree we simply have two drivers > talking to the I2C interface - sibyte/swarm/rtc_* and i2c-sibyte.c, > and they are currently lacking even any trivial locking. We haven't > seen any problems yet but that's due to limited exercise - the default > config doesn't hook up any drivers for the other chips on I2C. > > How do other arches that have I2C RTCs deal with this problem? Or is > there something wrong with how arch/mips/kernel/time.c:time_init deals > with the rtc? On ARM, where we have I2C RTCs, I tend to leave xtime well alone in time_init and just setup the timer. When i2c is initialised, and the bus and RTC have been detected, I set the time from them at that point. I haven't seen any problems with this approach. In fact, I'd rather time_init() just setup the timer, and we set the time of day later during the kernels initialisation. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core From ddaney@avtrex.com Thu Nov 3 00:44:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 00:45:14 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:32545 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133833AbVKCAo4 (ORCPT ); Thu, 3 Nov 2005 00:44:56 +0000 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 16:45:40 -0800 Message-ID: <43695DB4.7060708@avtrex.com> Date: Wed, 02 Nov 2005 16:45:40 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sjhill@realitydiluted.com CC: crossgcc@sources.redhat.com, MIPS Linux List Subject: Re: linux kernel building for mips malta target board References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Nov 2005 00:45:40.0843 (UTC) FILETIME=[EA3573B0:01C5E00F] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9408 X-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 sjhill@realitydiluted.com wrote: >>>I would like to build latest kernel (ie kernel 2.6.13) for mips malta >>>board. Can any one advise me the cross-compiler tools version to be >>>used for building the linux kernel. >>> >> >>I use both gcc-3.3.1 and gcc-3.4.3 to build 2.6.x mips linux kernels. I >>think for the 2.6.13 kernel any of the latest released versions of >>3.3.x, 3.4.x, or 4.0.x would work. Use the latest binutils (2.16.91 >>20050817 is what I am using). >> > > Also, make sure to NOT use any of the 4.1 GCC stuff with Linux/MIPS > kernels. I am still tracking down errors with it. > Is this the problem you are seeing?: In file included from include/linux/nfs_fs.h:15, from init/do_mounts.c:12: include/linux/pagemap.h: In function ‘fault_in_pages_readable’: include/linux/pagemap.h:236: error: read-only variable ‘__gu_val’ used as ‘asm’ output include/linux/pagemap.h:236: error: read-only variable ‘__gu_val’ used as ‘asm’ output include/linux/pagemap.h:236: error: read-only variable ‘__gu_val’ used as ‘asm’ output include/linux/pagemap.h:236: error: read-only variable ‘__gu_val’ used as ‘asm’ output The compiler behavior has changed since 4.0.1, but I think the new behavior is correct. I am blaming the __get_user macro in include/asm-mips/uaccess.h. It should be possible to fix it there. The alternative is to hack up include/linux/pagemap.h. David Daney From anderson@netsweng.com Thu Nov 3 01:02:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 01:02:43 +0000 (GMT) Received: from grayson.netsweng.com ([207.235.77.11]:29850 "EHLO grayson.netsweng.com") by ftp.linux-mips.org with ESMTP id S8133833AbVKCBCX (ORCPT ); Thu, 3 Nov 2005 01:02:23 +0000 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1EXTVR-0003ze-00; Wed, 02 Nov 2005 20:03:05 -0500 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14753-05; Wed, 2 Nov 2005 20:02:58 -0500 (EST) Received: from h168.98.28.71.ip.alltel.net ([71.28.98.168] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1EXTVJ-0003zV-00; Wed, 02 Nov 2005 20:02:58 -0500 Date: Wed, 2 Nov 2005 20:02:56 -0500 (EST) From: Stuart Anderson X-X-Sender: anderson@trantor.stuart.netsweng.com To: crossgcc@sources.redhat.com cc: MIPS Linux List Subject: Re: linux kernel building for mips malta target board In-Reply-To: <43695DB4.7060708@avtrex.com> Message-ID: References: <43695DB4.7060708@avtrex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netsweng.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anderson@netsweng.com Precedence: bulk X-list: linux-mips On Wed, 2 Nov 2005, David Daney wrote: > Is this the problem you are seeing?: > In file included from include/linux/nfs_fs.h:15, > from init/do_mounts.c:12: > include/linux/pagemap.h: In function fault_in_pages_readable: > include/linux/pagemap.h:236: error: read-only variable __gu_val used as > asm output > include/linux/pagemap.h:236: error: read-only variable __gu_val used as > asm output > include/linux/pagemap.h:236: error: read-only variable __gu_val used as > asm output > include/linux/pagemap.h:236: error: read-only variable __gu_val used as > asm output > > The compiler behavior has changed since 4.0.1, but I think the new behavior > is correct. I am blaming the __get_user macro in include/asm-mips/uaccess.h. > It should be possible to fix it there. The alternative is to hack up > include/linux/pagemap.h. __get_user() is unhappy, with tpyes that are "const". It uses __typeof() to create a local variable that it wants to write to. I've intended to have offer up a patch by now, but, too manyunexpected thing have happened in the firs thalf of this week. Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From ddaney@avtrex.com Thu Nov 3 01:19:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 01:19:25 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:33291 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133838AbVKCBTH (ORCPT ); Thu, 3 Nov 2005 01:19:07 +0000 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 17:19:51 -0800 Message-ID: <436965B7.3000606@avtrex.com> Date: Wed, 02 Nov 2005 17:19:51 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stuart Anderson CC: crossgcc@sources.redhat.com, MIPS Linux List Subject: Re: linux kernel building for mips malta target board References: <43695DB4.7060708@avtrex.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2005 01:19:51.0618 (UTC) FILETIME=[B090E220:01C5E014] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9410 X-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 Stuart Anderson wrote: > On Wed, 2 Nov 2005, David Daney wrote: > >> Is this the problem you are seeing?: >> In file included from include/linux/nfs_fs.h:15, >> from init/do_mounts.c:12: >> include/linux/pagemap.h: In function fault_in_pages_readable: >> include/linux/pagemap.h:236: error: read-only variable __gu_val >> used as asm output >> include/linux/pagemap.h:236: error: read-only variable __gu_val >> used as asm output >> include/linux/pagemap.h:236: error: read-only variable __gu_val >> used as asm output >> include/linux/pagemap.h:236: error: read-only variable __gu_val >> used as asm output >> >> The compiler behavior has changed since 4.0.1, but I think the new >> behavior is correct. I am blaming the __get_user macro in >> include/asm-mips/uaccess.h. It should be possible to fix it there. >> The alternative is to hack up include/linux/pagemap.h. > > > __get_user() is unhappy, with tpyes that are "const". It uses __typeof() > to create a local variable that it wants to write to. I've intended to > have offer up a patch by now, but, too manyunexpected thing have > happened in the firs thalf of this week. > That is my analysis as well. The typeof converts the const char * into a const char which is then unsuitable as the destination in an inline asm. David Daney From clem.taylor@gmail.com Thu Nov 3 01:34:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 01:35:03 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.198]:124 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133833AbVKCBel convert rfc822-to-8bit (ORCPT ); Thu, 3 Nov 2005 01:34:41 +0000 Received: by xproxy.gmail.com with SMTP id h27so469539wxd for ; Wed, 02 Nov 2005 17:35:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ki005+7wK4toC89NsIUA2pjdj7r1w8vkTsM3Iwohnr7S7SfiOZ0AFrQjofNjqOGvKcKpmscO6/Ti9U0QWfdKx4XX3ZXUPAgnf1MzNUVRKsd8lKT5Z38HWT1pD4hAUiepW2jN+x4r9oMYX3HPqUUlS0bfQzphyiIAyklqonIvbqg= Received: by 10.70.35.10 with SMTP id i10mr115788wxi; Wed, 02 Nov 2005 17:35:26 -0800 (PST) Received: by 10.70.130.1 with HTTP; Wed, 2 Nov 2005 17:35:25 -0800 (PST) Message-ID: Date: Wed, 2 Nov 2005 20:35:25 -0500 From: Clem Taylor To: linux-mips Subject: 2.6.14 on Au1550 panics in free_hot_cold_page from init MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9411 X-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 Hi, I was wondering if anyone has gotten 2.6.14 to run on an Au1550. I had 2.6.14-rc2 mostly working (except for jffs2 writes) and was previously using 2.6.13 (had a jffs2 sync problem on reboot) and 2.6.11 (seems okay). I tried out a linux-mips-git tree from this afternoon (6e47ab8b0ad1ca7bddbc086e2ce7736632c18df4). 2.6.14 is panicing right after the 'Freeing unused kernel memory' with: Linux version 2.6.14 (ctaylor@gort) (gcc version 3.4.4) #5 Wed Nov 2 20:06:54 EST 2005 CPU revision is: 03030200 Aquila 1550 Network Processor Board (PRId 03030200) @ 492MHZ BCLK switching enabled! Determined physical RAM map: memory: 04000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: root=/dev/nfs ip=bootp console=ttyS1,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: 512 (order: 9, 8192 bytes) calculating r4koff... 000781e0(492000) CPU frequency 492.00 MHz warning: LCD clock too high (61500 KHz) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 61312k/65536k available (1896k kernel code, 4096k reserved, 275k data, 136k init, 0k highmem) Mount-cache hash table entries: 512 Checking for 'wait' instruction... unavailable. NET: Registered protocol family 16 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. 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 au1000eth version 1.5 Pete Popov 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: Au1x No known MII transceivers found! Aquila1550 Flash: probing 16-bit flash bus Aquila1550 Flash: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 Aquila1550 Flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. Creating 6 MTD partitions on "Aquila1550 Flash": 0x00000000-0x00e00000 : "0xbe000000:image0" 0x00e00000-0x01c00000 : "0xbee00000:image1" 0x01c00000-0x01c80000 : "0xbfc00000:u-boot" 0x01c80000-0x01fc0000 : "0xbfc80000:params" 0x01fc0000-0x01fe0000 : "0xbffc0000:u-boot env" 0x01fe0000-0x02000000 : "0xbffe0000:u-boot envcpy" i2c /dev entries driver Au1550 I2C: initialized. NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered TCP bic registered NET: Registered protocol family 1 Sending BOOTP requests .<6>eth0: going to full duplex . OK IP-Config: Got BOOTP answer from 192.168.50.23, my address is 192.168.50.243 IP-Config: Complete: device=eth0, addr=192.168.50.243, mask=255.255.255.0, gw=192.168.50.1, host=192.168.50.243, domain=, nis-domain=(none), bootserver=192.168.50.23, rootserver=192.168.50.23, rootpath=/aquilaroot-cgt Looking up port of RPC 100003/2 on 192.168.50.23 Looking up port of RPC 100005/1 on 192.168.50.23 VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 136k freed Bad page state at free_hot_cold_page (in process 'init', page 81006c80) flags:0x00000400 mapping:00000000 mapcount:0 count:0 Backtrace: Call Trace: [<801510b0>] bad_page+0x70/0xb4 [<801517c0>] free_hot_cold_page+0x84/0x1d8 [<80161848>] do_wp_page+0x34c/0x7e0 [<801619d8>] do_wp_page+0x4dc/0x7e0 [<801695f8>] page_add_anon_rmap+0x0/0xe0 [<8021d054>] uart_open+0x1d8/0xab4 [<80331ee4>] vfs_caches_init_early+0x94/0xc0 [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<80162b4c>] __handle_mm_fault+0x920/0x1038 [<8033bd3c>] ip_misc_proc_init+0xa0/0xf8 [<80333a20>] ipc_init_ids+0x20/0xbc [<8017f598>] chrdev_open+0xa0/0x140 [<80189130>] may_open+0x5c/0x290 [<8033bd30>] ip_misc_proc_init+0x94/0xf8 [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<80331ee4>] vfs_caches_init_early+0x94/0xc0 [<8010ebdc>] do_page_fault+0xfc/0x3d0 [<8016da08>] nameidata_to_filp+0x30/0x64 [<8018e1e4>] do_ioctl+0x54/0x90 [<8018e420>] vfs_ioctl+0x200/0x3a4 [<8016ddcc>] get_unused_fd+0x118/0x1cc [<8018e614>] sys_ioctl+0x50/0x9c [<8016dffc>] do_sys_open+0xe4/0xec [<8010f5e8>] tlb_do_page_fault_1+0x100/0x108 [<8010404c>] work_resched+0x8/0x40 Trying to fix it up, but a reboot is needed init started: BusyBox v1.00 (2005.09.24-00:33+0000) multi-call binary Break instruction in kernel code[#1]: Cpu 0 $ 0 : 00000000 1000fc00 00000001 00000000 $ 4 : 81006c80 81006c80 00000000 00000000 $ 8 : 00000000 00000000 000000d8 0000d918 $12 : 80340000 81006c80 8032e590 2ab97a4c $16 : 8112c008 80000000 00000590 004b2130 $20 : 803314ec 8033bd00 00000000 8032e590 $24 : 2ab926dc 2abb3834 $28 : 810a0000 810a1dd0 80350000 801626d8 Hi : 00000000 Lo : 0000012c epc : 801697c0 page_add_file_rmap+0xe8/0xf4 Tainted: G B ra : 801626d8 __handle_mm_fault+0x4ac/0x1038 Status: 1000fc03 KERNEL EXL IE Cause : 00800024 PrId : 03030200 Process init (pid: 1, threadinfo=810a0000, task=8036bbe8) Stack : 803772a0 80333998 01b42f73 00000004 810ad005 00001000 810a1ed0 810a1ed0 00000000 00000000 00000000 00000000 000000d8 0000d918 000000d8 0000d918 000000d8 0000d918 810a1f18 7f90fc00 80374aa8 803772a0 004ba000 8033bd00 004b9000 00000401 00000001 00000000 8033bd30 8036bbe8 8033bd00 004b2130 803314ec 810a1f30 00030000 00000000 004683f0 8010ebdc 8033f9f0 801bd9f0 ... Call Trace: [<80333998>] ipc_init_proc_interface+0x58/0xc0 [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<8033bd30>] ip_misc_proc_init+0x94/0xf8 [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<803314ec>] kmem_cache_init+0x1c8/0x58c [<8010ebdc>] do_page_fault+0xfc/0x3d0 [<801bd9f0>] nfs_permission+0xf8/0x208 [<80188018>] path_lookup+0xe0/0x3d0 [<80184cd8>] getname+0x28/0xf8 [<80333998>] ipc_init_proc_interface+0x58/0xc0 [<8019430c>] dput+0x190/0x21c [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<80185138>] path_release+0x18/0xd4 [<8016cd30>] sys_access+0x15c/0x164 [<80333998>] ipc_init_proc_interface+0x58/0xc0 [<8033bd00>] ip_misc_proc_init+0x64/0xf8 [<8016efcc>] sys_read+0x54/0xa0 [<80167030>] sys_brk+0x118/0x15c [<8016dffc>] do_sys_open+0xe4/0xec [<8010f4e0>] tlb_do_page_fault_0+0x100/0x108 [<8010d0c0>] stack_done+0x20/0x3c Code: 0200000d 0805a5c4 3c028034 <0200000d> 0805a5bb 3c038035 3c028034 8c4326e8 3c020002 Kernel panic - not syncing: Attempted to kill init! This is without support for the PCI device. With support for the PCI device it fails in a similar path, but from pci_scan_single_device. Any ideas what might be going on? Is anyone working with 2.6.14 with the Au1550 (or Au1xxx) processors? Thanks, Clem From anderson@netsweng.com Thu Nov 3 02:20:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 02:20:54 +0000 (GMT) Received: from grayson.netsweng.com ([207.235.77.11]:37533 "EHLO grayson.netsweng.com") by ftp.linux-mips.org with ESMTP id S8133833AbVKCCUK (ORCPT ); Thu, 3 Nov 2005 02:20:10 +0000 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1EXUih-00055u-00; Wed, 02 Nov 2005 21:20:51 -0500 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19317-02; Wed, 2 Nov 2005 21:20:40 -0500 (EST) Received: from h168.98.28.71.ip.alltel.net ([71.28.98.168] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1EXUiU-00055g-00; Wed, 02 Nov 2005 21:20:38 -0500 Date: Wed, 2 Nov 2005 21:20:35 -0500 (EST) From: Stuart Anderson X-X-Sender: anderson@trantor.stuart.netsweng.com To: David Daney cc: crossgcc@sources.redhat.com, MIPS Linux List Subject: Re: linux kernel building for mips malta target board In-Reply-To: <436965B7.3000606@avtrex.com> Message-ID: References: <43695DB4.7060708@avtrex.com> <436965B7.3000606@avtrex.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811327-1060407037-1130984435=:3511" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netsweng.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anderson@netsweng.com Precedence: bulk X-list: linux-mips This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811327-1060407037-1130984435=:3511 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 2 Nov 2005, David Daney wrote: >> __get_user() is unhappy, with tpyes that are "const". It uses __typeof() >> to create a local variable that it wants to write to. I've intended to >> have offer up a patch by now, but, too many unexpected thing have happened >> in the firs thalf of this week. I shamed myself into sitting down and doing this. 8-) The attached patch seems to work, or at least doesn't seem to cause things to blow up. An o32 userspace on a 64-bit kernel comes up multi-user and can build a kernel, and run a quick subset of LTP. There was a comment on IRC that there was a register allocation issue which lead to the current code. I'm not sure of the exact details, but I _think_ this change ends up being equivilent to the code it replaces. Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ---1463811327-1060407037-1130984435=:3511 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: uaccess.h.patch Content-Disposition: attachment; filename=diff SW5kZXg6IHVhY2Nlc3MuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0t IHVhY2Nlc3MuaAkocmV2aXNpb24gODQpDQorKysgdWFjY2Vzcy5oCSh3b3Jr aW5nIGNvcHkpDQpAQCAtMjEwLDE3ICsyMTAsMzUgQEANCiANCiAjZGVmaW5l IF9fZ2V0X3VzZXJfbm9jaGVjayh4LHB0cixzaXplKQkJCQkJXA0KICh7CQkJ CQkJCQkJXA0KLQlfX3R5cGVvZigqKHB0cikpIF9fZ3VfdmFsID0gIChfX3R5 cGVvZigqKHB0cikpKSAwOwkJXA0KIAlsb25nIF9fZ3VfZXJyID0gMDsJCQkJ CQlcDQogCQkJCQkJCQkJXA0KIAlzd2l0Y2ggKHNpemUpIHsJCQkJCQkJXA0K LQljYXNlIDE6IF9fZ2V0X3VzZXJfYXNtKCJsYiIsIHB0cik7IGJyZWFrOwkJ CVwNCi0JY2FzZSAyOiBfX2dldF91c2VyX2FzbSgibGgiLCBwdHIpOyBicmVh azsJCQlcDQotCWNhc2UgNDogX19nZXRfdXNlcl9hc20oImx3IiwgcHRyKTsg YnJlYWs7CQkJXA0KLQljYXNlIDg6IF9fR0VUX1VTRVJfRFcocHRyKTsgYnJl YWs7CQkJCVwNCisJY2FzZSAxOiB7CQkJCQkJCVwNCisJCXM4IF9fZ3VfdmFs ID0gIChzOCkgMDsJCQkJCVwNCisJCV9fZ2V0X3VzZXJfYXNtKCJsYiIsIHB0 cik7IAkJCQlcDQorCQkoeCkgPSAoX190eXBlb2ZfXygqKHB0cikpKSBfX2d1 X3ZhbDsJCQlcDQorCQlicmVhazsJCQkJCQkJXA0KKwkJfQkJCQkJCQlcDQor CWNhc2UgMjoJewkJCQkJCQlcDQorCQlzMTYgX19ndV92YWwgPSAgKHMxNikg MDsJCQkJXA0KKwkJX19nZXRfdXNlcl9hc20oImxoIiwgcHRyKTsJCQkJXA0K KwkJKHgpID0gKF9fdHlwZW9mX18oKihwdHIpKSkgX19ndV92YWw7CQkJXA0K KwkJYnJlYWs7CQkJCQkJCVwNCisJCX0JCQkJCQkJXA0KKwljYXNlIDQ6CXsJ CQkJCQkJXA0KKwkJczMyIF9fZ3VfdmFsID0gKHMzMikgMDsJCQkJCVwNCisJ CV9fZ2V0X3VzZXJfYXNtKCJsdyIsIHB0cik7CQkJCVwNCisJCSh4KSA9IChf X3R5cGVvZl9fKCoocHRyKSkpIF9fZ3VfdmFsOwkJCVwNCisJCWJyZWFrOwkJ CQkJCQlcDQorCQl9CQkJCQkJCVwNCisJY2FzZSA4Ogl7CQkJCQkJCVwNCisJ CXM2NCBfX2d1X3ZhbCA9IChzNjQpIDA7CQkJCQlcDQorCQlfX0dFVF9VU0VS X0RXKHB0cik7CQkJCQlcDQorCQkoeCkgPSAoX190eXBlb2ZfXygqKHB0cikp KSBfX2d1X3ZhbDsJCQlcDQorCQlicmVhazsJCQkJCQkJXA0KKwkJfQkJCQkJ CQlcDQogCWRlZmF1bHQ6IF9fZ2V0X3VzZXJfdW5rbm93bigpOyBicmVhazsJ CQkJXA0KIAl9CQkJCQkJCQlcDQotCSh4KSA9IChfX3R5cGVvZl9fKCoocHRy KSkpIF9fZ3VfdmFsOwkJCQlcDQogCV9fZ3VfZXJyOwkJCQkJCQlcDQogfSkN CiANCg== ---1463811327-1060407037-1130984435=:3511-- From ralf@linux-mips.org Thu Nov 3 11:05:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 11:05:30 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:16666 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133388AbVKCLFM (ORCPT ); Thu, 3 Nov 2005 11:05:12 +0000 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 jA3B5tCO006023; Thu, 3 Nov 2005 11:05:56 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA3B5rgR006022; Thu, 3 Nov 2005 11:05:53 GMT Date: Thu, 3 Nov 2005 11:05:53 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] remove mips_rtc_lock Message-ID: <20051103110552.GA3149@linux-mips.org> References: <20051103.010240.41630907.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103.010240.41630907.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9413 X-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 On Thu, Nov 03, 2005 at 01:02:40AM +0900, Atsushi Nemoto wrote: > The mips_rtc_lock is no longer needed because RTC operations should be > protected already by other mechanism. (rtc_lock, local_irq_save, etc.) > > Also, locking whole rtc_get_time/rtc_set_time should be avoided while > some RTC routines might take very long time (a few seconds). > > Signed-off-by: Atsushi Nemoto Applied. Thanks alot for the janitor work. And also the function names are clear as mud: [...] static inline unsigned int get_rtc_time(struct rtc_time *time) { unsigned long nowtime; nowtime = rtc_get_time(); [...] static inline int set_rtc_time(struct rtc_time *time) { unsigned long nowtime; int ret; nowtime = mktime(time->tm_year+1900, time->tm_mon+1, time->tm_mday, time->tm_hour, time->tm_min, time->tm_sec); ret = rtc_set_time(nowtime); [...] The difference between and get_rtc_time and rtc_get_time is less than obvious. Same for set_rtc_time and rtc_set_time ... Ralf From ralf@linux-mips.org Thu Nov 3 12:58:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 12:58:59 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:51733 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133844AbVKCM6m (ORCPT ); Thu, 3 Nov 2005 12:58:42 +0000 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 jA3CxRMu009675; Thu, 3 Nov 2005 12:59:27 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA3CxQfB009674; Thu, 3 Nov 2005 12:59:26 GMT Date: Thu, 3 Nov 2005 12:59:26 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, "Maciej W. Rozycki" Subject: Re: [PATCH] use rtc_lock to protect RTC operations Message-ID: <20051103125926.GB3149@linux-mips.org> References: <20051103.010115.07642880.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103.010115.07642880.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9414 X-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 On Thu, Nov 03, 2005 at 01:01:15AM +0900, Atsushi Nemoto wrote: > Many RTC routines are not protected each other. There are potential > race, for example, ntp-update and /dev/rtc. This patch fixes them > using rtc_lock. > > Signed-off-by: Atsushi Nemoto > --- a/arch/mips/dec/time.c > +++ b/arch/mips/dec/time.c > @@ -37,10 +37,25 @@ > #include > > > +/* > + * Returns true if a clock update is in progress > + */ > +static inline unsigned char dec_rtc_is_updating(void) > +{ > + unsigned char uip; > + unsigned long flags; > + > + spin_lock_irqsave(&rtc_lock, flags); > + uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP); > + spin_unlock_irqrestore(&rtc_lock, flags); Unlike on PC CMOS_READ on a DEC is a single read operation, so atomic and so doesn't need to be protected. I'd have to check the datasheet for any other reason why it might need locking though, so I apply your patch for now and leave this to Maciej for later optimization. Ralf From macro@linux-mips.org Thu Nov 3 13:14:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 13:14:59 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:4879 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133850AbVKCNOk (ORCPT ); Thu, 3 Nov 2005 13:14:40 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 838FAE1C91; Thu, 3 Nov 2005 14:15:24 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30479-06; Thu, 3 Nov 2005 14:15:24 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 325B4E1C67; Thu, 3 Nov 2005 14:15:23 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jA3DFGXY025647; Thu, 3 Nov 2005 14:15:16 +0100 Date: Thu, 3 Nov 2005 13:15:32 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] use rtc_lock to protect RTC operations In-Reply-To: <20051103125926.GB3149@linux-mips.org> Message-ID: References: <20051103.010115.07642880.anemo@mba.ocn.ne.jp> <20051103125926.GB3149@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1160/Wed Nov 2 17:26:43 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9415 X-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, 3 Nov 2005, Ralf Baechle wrote: > Unlike on PC CMOS_READ on a DEC is a single read operation, so atomic > and so doesn't need to be protected. I'd have to check the datasheet > for any other reason why it might need locking though, so I apply your > patch for now and leave this to Maciej for later optimization. You are correct -- unless you need to perform multiple RTC access cycles uninterrupted in a row, a lock is not needed. Single accesses are executed as single cycles on the system bus, with some glue logic attached to the RTC chip converting them into pairs of chip accesses consisting of an index register write and the actual data cycle. Even the exact latency of the whole operation is specified for some system models. ;-) Welcome to a clean design! Maciej From anemo@mba.ocn.ne.jp Thu Nov 3 13:37:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 13:37:39 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:7893 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133847AbVKCNhV (ORCPT ); Thu, 3 Nov 2005 13:37:21 +0000 Received: from localhost (p4179-ipad210funabasi.chiba.ocn.ne.jp [58.88.123.179]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C23D1A2C1; Thu, 3 Nov 2005 22:38:05 +0900 (JST) Date: Thu, 03 Nov 2005 22:37:05 +0900 (JST) Message-Id: <20051103.223705.74752861.anemo@mba.ocn.ne.jp> To: macro@linux-mips.org Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] use rtc_lock to protect RTC operations From: Atsushi Nemoto In-Reply-To: References: <20051103.010115.07642880.anemo@mba.ocn.ne.jp> <20051103125926.GB3149@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.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9416 X-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, 3 Nov 2005 13:15:32 +0000 (GMT), "Maciej W. Rozycki" said: >> Unlike on PC CMOS_READ on a DEC is a single read operation, so >> atomic and so doesn't need to be protected. I'd have to check the >> datasheet for any other reason why it might need locking though, so >> I apply your patch for now and leave this to Maciej for later >> optimization. macro> You are correct -- unless you need to perform multiple RTC macro> access cycles uninterrupted in a row, a lock is not needed. Then the dec_rtc_is_updating would be one liner: return (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP); What good hardware! --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Nov 3 14:13:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 14:13:22 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:45777 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133848AbVKCONF (ORCPT ); Thu, 3 Nov 2005 14:13:05 +0000 Received: from localhost (p4179-ipad210funabasi.chiba.ocn.ne.jp [58.88.123.179]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 282ADA8B5; Thu, 3 Nov 2005 23:13:51 +0900 (JST) Date: Thu, 03 Nov 2005 23:12:50 +0900 (JST) Message-Id: <20051103.231250.25477564.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] remove mips_rtc_lock From: Atsushi Nemoto In-Reply-To: <20051103110552.GA3149@linux-mips.org> References: <20051103.010240.41630907.anemo@mba.ocn.ne.jp> <20051103110552.GA3149@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.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9417 X-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, 3 Nov 2005 11:05:53 +0000, Ralf Baechle said: ralf> The difference between and get_rtc_time and rtc_get_time is less ralf> than obvious. Same for set_rtc_time and rtc_set_time ... Sure. Also I suppose majority of RTC prefer struct rtc_time than unsigned long. Is it time for redesign the mips RTC interface? ;-) --- Atsushi Nemoto From ralf@linux-mips.org Thu Nov 3 14:26:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 14:26:17 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:63238 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133850AbVKCO0A (ORCPT ); Thu, 3 Nov 2005 14:26:00 +0000 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 jA3EQj1a016765; Thu, 3 Nov 2005 14:26:45 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA3EQhEH016764; Thu, 3 Nov 2005 14:26:43 GMT Date: Thu, 3 Nov 2005 14:26:43 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] remove mips_rtc_lock Message-ID: <20051103142642.GA16434@linux-mips.org> References: <20051103.010240.41630907.anemo@mba.ocn.ne.jp> <20051103110552.GA3149@linux-mips.org> <20051103.231250.25477564.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103.231250.25477564.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9418 X-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 On Thu, Nov 03, 2005 at 11:12:50PM +0900, Atsushi Nemoto wrote: > >>>>> On Thu, 3 Nov 2005 11:05:53 +0000, Ralf Baechle said: > > ralf> The difference between and get_rtc_time and rtc_get_time is less > ralf> than obvious. Same for set_rtc_time and rtc_set_time ... > > Sure. Also I suppose majority of RTC prefer struct rtc_time than > unsigned long. Is it time for redesign the mips RTC interface? ;-) More than that, the whole MIPS time code while functional is such a beauty it could make a grown man cry ... Ralf From ralf@linux-mips.org Thu Nov 3 16:32:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 16:32:44 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:28431 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133860AbVKCQc1 (ORCPT ); Thu, 3 Nov 2005 16:32:27 +0000 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 jA3GXBVM026798; Thu, 3 Nov 2005 16:33:11 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA3GX6Jt026786; Thu, 3 Nov 2005 16:33:06 GMT Date: Thu, 3 Nov 2005 16:33:06 +0000 From: Ralf Baechle To: Stuart Anderson Cc: David Daney , crossgcc@sources.redhat.com, MIPS Linux List Subject: Re: linux kernel building for mips malta target board Message-ID: <20051103163306.GC3149@linux-mips.org> References: <43695DB4.7060708@avtrex.com> <436965B7.3000606@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9419 X-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 > I shamed myself into sitting down and doing this. 8-) > > The attached patch seems to work, or at least doesn't seem to cause > things to blow up. An o32 userspace on a 64-bit kernel comes up > multi-user and can build a kernel, and run a quick subset of LTP. > > There was a comment on IRC that there was a register allocation issue which > lead to the current code. I'm not sure of the exact details, but I _think_ > this change ends up being equivilent to the code it replaces. It's correct - but triggers plenty of extra warnings and you forgot about get_user() which has the same kind of issue. Also you don't have the guarantee that has been included, so in order to avoid a yet another header file dependency I changed s8, s16 etc. to char, short, int, long long. Working on it but as usual uaccess.h is quite a quiz. Ralf From ralf@linux-mips.org Thu Nov 3 17:59:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 17:59:20 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:34843 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133864AbVKCR7D (ORCPT ); Thu, 3 Nov 2005 17:59:03 +0000 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 jA3Hxlh0030322; Thu, 3 Nov 2005 17:59:47 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA3HxkIV030321; Thu, 3 Nov 2005 17:59:46 GMT Date: Thu, 3 Nov 2005 17:59:46 +0000 From: Ralf Baechle To: Clem Taylor Cc: linux-mips Subject: Re: 2.6.14 on Au1550 panics in free_hot_cold_page from init Message-ID: <20051103175945.GA7461@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9420 X-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 On Wed, Nov 02, 2005 at 08:35:25PM -0500, Clem Taylor wrote: > I was wondering if anyone has gotten 2.6.14 to run on an Au1550. I had > 2.6.14-rc2 mostly working (except for jffs2 writes) and was previously > using 2.6.13 (had a jffs2 sync problem on reboot) and 2.6.11 (seems > okay). > > I tried out a linux-mips-git tree from this afternoon > (6e47ab8b0ad1ca7bddbc086e2ce7736632c18df4). 2.6.14 is panicing right > after the 'Freeing unused kernel memory' with: What you're running is actually post-linux 2.6.14 already, with a few megs of finest breakage of Linus merged in. I suggest you try what's tagged as linux-2.6.14 instead. I'm currently aggressivly following Linus and so the repository is gets all the good and bad stuff from kernel.org in undilluted form on the master branch. Ralf From ppopov@embeddedalley.com Thu Nov 3 18:06:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Nov 2005 18:07:04 +0000 (GMT) Received: from web403.biz.mail.mud.yahoo.com ([68.142.201.34]:36992 "HELO web403.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133872AbVKCSGq (ORCPT ); Thu, 3 Nov 2005 18:06:46 +0000 Received: (qmail 67849 invoked by uid 60001); 3 Nov 2005 18:07:30 -0000 Message-ID: <20051103180730.67847.qmail@web403.biz.mail.mud.yahoo.com> Received: from [161.88.255.139] by web403.biz.mail.mud.yahoo.com via HTTP; Thu, 03 Nov 2005 10:07:30 PST Date: Thu, 3 Nov 2005 10:07:30 -0800 (PST) From: Peter Popov Subject: Re: 2.6.14 on Au1550 panics in free_hot_cold_page from init To: Ralf Baechle , Clem Taylor Cc: linux-mips In-Reply-To: <20051103175945.GA7461@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9421 X-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 Just to confirm what Ralf said - 2.6.13 runs fine on my board so this is a new problem. Pete --- Ralf Baechle wrote: > On Wed, Nov 02, 2005 at 08:35:25PM -0500, Clem > Taylor wrote: > > > I was wondering if anyone has gotten 2.6.14 to run > on an Au1550. I had > > 2.6.14-rc2 mostly working (except for jffs2 > writes) and was previously > > using 2.6.13 (had a jffs2 sync problem on reboot) > and 2.6.11 (seems > > okay). > > > > I tried out a linux-mips-git tree from this > afternoon > > (6e47ab8b0ad1ca7bddbc086e2ce7736632c18df4). 2.6.14 > is panicing right > > after the 'Freeing unused kernel memory' with: > > What you're running is actually post-linux 2.6.14 > already, with a few > megs of finest breakage of Linus merged in. I > suggest you try > what's tagged as linux-2.6.14 instead. > > I'm currently aggressivly following Linus and so the > repository is gets > all the good and bad stuff from kernel.org in > undilluted form on the > master branch. > > Ralf > > From anemo@mba.ocn.ne.jp Fri Nov 4 17:03:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Nov 2005 17:03:43 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:31979 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S3466428AbVKDRDE (ORCPT ); Fri, 4 Nov 2005 17:03:04 +0000 Received: from localhost (p8154-ipad32funabasi.chiba.ocn.ne.jp [221.189.140.154]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 87250A499; Sat, 5 Nov 2005 02:03:54 +0900 (JST) Date: Sat, 05 Nov 2005 02:02:54 +0900 (JST) Message-Id: <20051105.020254.41196576.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] define MAX_UDELAY_MS From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9422 X-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 If HZ was 1000, mdelay(2) cause overflow on multiplication in __udelay. We should define MAX_UDELAY_MS properly to prevent this. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/delay.h b/include/asm-mips/delay.h --- a/include/asm-mips/delay.h +++ b/include/asm-mips/delay.h @@ -84,4 +84,13 @@ static inline void __udelay(unsigned lon #define udelay(usecs) __udelay((usecs),__udelay_val) +/* make sure "usecs *= ..." in udelay do not overflow. */ +#if HZ >= 1000 +#define MAX_UDELAY_MS 1 +#elif HZ <= 200 +#define MAX_UDELAY_MS 5 +#else +#define MAX_UDELAY_MS (1000 / HZ) +#endif + #endif /* _ASM_DELAY_H */ From ralf@linux-mips.org Fri Nov 4 17:17:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Nov 2005 17:17:35 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:35599 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3466431AbVKDRRR (ORCPT ); Fri, 4 Nov 2005 17:17:17 +0000 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 jA4HI7jb007487; Fri, 4 Nov 2005 17:18:07 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA4HI5Ri007486; Fri, 4 Nov 2005 17:18:05 GMT Date: Fri, 4 Nov 2005 17:18:05 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] define MAX_UDELAY_MS Message-ID: <20051104171805.GF2694@linux-mips.org> References: <20051105.020254.41196576.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051105.020254.41196576.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9423 X-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 On Sat, Nov 05, 2005 at 02:02:54AM +0900, Atsushi Nemoto wrote: > If HZ was 1000, mdelay(2) cause overflow on multiplication in > __udelay. We should define MAX_UDELAY_MS properly to prevent this. Applied, Ralf From n_tbinh@yahoo.com Sat Nov 5 07:12:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Nov 2005 07:12:30 +0000 (GMT) Received: from web30705.mail.mud.yahoo.com ([68.142.200.138]:44625 "HELO web30705.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133547AbVKEHML (ORCPT ); Sat, 5 Nov 2005 07:12:11 +0000 Received: (qmail 60440 invoked by uid 60001); 5 Nov 2005 07:13:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pR4pF1rVZVSO1228gmAxk3TSAjggEaQioFdCwCvo2s+woEwneg7wyHbB6AbH4YgMC/Nl0svaumjmy71bgwv4nSul0rhImd/L4UliJdT5dawUkHFZ6qfcw+FajprKK9HMtgbybjW1e0eMYzhxEi2AKzhdJ1xwDhaW3yIZTW/ddVk= ; Message-ID: <20051105071303.60438.qmail@web30705.mail.mud.yahoo.com> Received: from [203.190.168.9] by web30705.mail.mud.yahoo.com via HTTP; Sat, 05 Nov 2005 07:13:03 GMT Date: Sat, 5 Nov 2005 07:13:03 +0000 (GMT) From: Nguyen Thanh Binh Subject: Booting with NFS fails To: linux-mips@linux-mips.org Cc: mlachwani@mvista.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: n_tbinh@yahoo.com Precedence: bulk X-list: linux-mips Hello all, I have installed Red Hat Enterprise 3 on the host (x86) and MontaVista Linux (previewkit) on the target (memec virtex-4 Fx12 LC board). When booting the target using NFS from the host, the following error appeared: eth0: Link carrier lost. eth0: Could not read PHY control register; error 1003 eth0: Terminating link monitoring. It is very strange, because ethernet does not work as the error shows but I can ping the target from the host with the IP got with DHCP. Your help or experience would be appreciated. Thank you. Nguyen Binh ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From m_lachwani@yahoo.com Sat Nov 5 09:07:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Nov 2005 09:08:17 +0000 (GMT) Received: from web30904.mail.mud.yahoo.com ([68.142.200.157]:21613 "HELO web30904.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133547AbVKEJH7 (ORCPT ); Sat, 5 Nov 2005 09:07:59 +0000 Received: (qmail 27446 invoked by uid 60001); 5 Nov 2005 09:08:52 -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=NcNDkKSeuO+yGsnfhyQI0Ju77DUIGl6fkNLzMgx1IJKZ6WvTVdwYy4J7gtsB/Rg9+NfcvZH6Bys81CcE6WIu4J3R6LusL3ZPzZsnHtJhkG7jhzC43R7k9xANb4tnlwsODFjgQd4SyBN/tRkI7J2z0MqkkIMMshRDLsH8jBVAp48= ; Message-ID: <20051105090852.27444.qmail@web30904.mail.mud.yahoo.com> Received: from [12.65.150.231] by web30904.mail.mud.yahoo.com via HTTP; Sat, 05 Nov 2005 01:08:52 PST Date: Sat, 5 Nov 2005 01:08:52 -0800 (PST) From: Manish Lachwani Subject: Re: Booting with NFS fails To: Nguyen Thanh Binh , linux-mips@linux-mips.org Cc: mlachwani@mvista.com In-Reply-To: <20051105071303.60438.qmail@web30705.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: m_lachwani@yahoo.com Precedence: bulk X-list: linux-mips Can you please post the complete boot log? Thanks Manish Lachwani --- Nguyen Thanh Binh wrote: > Hello all, > > I have installed Red Hat Enterprise 3 on the host > (x86) and MontaVista Linux (previewkit) on the > target > (memec virtex-4 Fx12 LC board). When booting the > target using NFS from the host, the following error > appeared: > > eth0: Link carrier lost. > eth0: Could not read PHY control register; error > 1003 > eth0: Terminating link monitoring. > > It is very strange, because ethernet does not work > as > the error shows but I can ping the target from the > host with the IP got with DHCP. > > Your help or experience would be appreciated. > > Thank you. > > Nguyen Binh > > > > > ___________________________________________________________ > > How much free photo storage do you get? Store your > holiday > snaps for FREE with Yahoo! Photos > http://uk.photos.yahoo.com > > From anemo@mba.ocn.ne.jp Sat Nov 5 14:01:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Nov 2005 14:01:27 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:44227 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133476AbVKEOBB (ORCPT ); Sat, 5 Nov 2005 14:01:01 +0000 Received: from localhost (p5048-ipad205funabasi.chiba.ocn.ne.jp [222.146.100.48]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 7E5F9AAE8; Sat, 5 Nov 2005 23:01:57 +0900 (JST) Date: Sat, 05 Nov 2005 23:00:58 +0900 (JST) Message-Id: <20051105.230058.25910302.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix return type of setup_frame variants From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9426 X-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 Since 2.6.13-rc1, setup_frame and its variants return int. But there are some remaining bits. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -384,9 +384,6 @@ give_sigsegv: return 0; } -extern void setup_rt_frame_n32(struct k_sigaction * ka, - struct pt_regs *regs, int signr, sigset_t *set, siginfo_t *info); - static inline int handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka, sigset_t *oldset, struct pt_regs *regs) { diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -647,8 +647,8 @@ static inline void *get_sigframe(struct return (void *)((sp - frame_size) & ALMASK); } -void setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, - int signr, sigset_t *set) +int setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, + int signr, sigset_t *set) { struct sigframe *frame; int err = 0; @@ -694,13 +694,15 @@ void setup_frame_32(struct k_sigaction * current->comm, current->pid, frame, regs->cp0_epc, frame->sf_code); #endif - return; + return 1; give_sigsegv: force_sigsegv(signr, current); + return 0; } -void setup_rt_frame_32(struct k_sigaction * ka, struct pt_regs *regs, int signr, sigset_t *set, siginfo_t *info) +int setup_rt_frame_32(struct k_sigaction * ka, struct pt_regs *regs, + int signr, sigset_t *set, siginfo_t *info) { struct rt_sigframe32 *frame; int err = 0; @@ -763,10 +765,11 @@ void setup_rt_frame_32(struct k_sigactio current->comm, current->pid, frame, regs->cp0_epc, frame->rs_code); #endif - return; + return 1; give_sigsegv: force_sigsegv(signr, current); + return 0; } static inline int handle_signal(unsigned long sig, siginfo_t *info, From maillist@jg555.com Sat Nov 5 18:56:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Nov 2005 18:56:19 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:39078 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133614AbVKES4B (ORCPT ); Sat, 5 Nov 2005 18:56:01 +0000 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; Sat, 05 Nov 2005 10:56:50 -0800 id 0028C43E.436D0072.000049D8 Message-ID: <436D0061.5070100@jg555.com> Date: Sat, 05 Nov 2005 10:56:33 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: MIPS - 64bit woes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9427 X-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 I've been working on getting the RaQ2 to work with the current 2.6.14 kernel, but no luck at all. The last success I had was with 2.6.12.x series. I'm looking for ideas, patches or whatever to get this working again. I know it has to do with the kernel using 32bit addressing instead of 64 bit, but have no clue where to start. Here is what I get when I attempt to boot it. > nfs 172.16.0.1 /nfsroot boot/vmlinux-2.6.14.gz nfs: mounted "/nfsroot" nfs: lookup "boot" nfs: lookup "vmlinux-2.6.14.gz" nfs: mode <0100755> 1349KB loaded (899KB/sec) 001512e8 1381096t nfs: unmounted "/nfsroot" > execute root=/dev/nfs nfsroot=172.16.0.1:/nfsroot console=ttyS0,115200 ip=dhcp elf64: 00080000 - 003b901f (ffffffff.80357000) (ffffffff.80000000) elf64: ffffffff.80080000 (80080000) 3170438t + 208794t net: interface down Thanx for all your assistance. -- ---- Jim Gifford maillist@jg555.com From kumba@gentoo.org Sat Nov 5 23:18:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Nov 2005 23:18:46 +0000 (GMT) Received: from sccrmhc13.comcast.net ([204.127.202.64]:15597 "EHLO sccrmhc13.comcast.net") by ftp.linux-mips.org with ESMTP id S8133631AbVKEXS3 (ORCPT ); Sat, 5 Nov 2005 23:18:29 +0000 Received: from [192.168.1.15] (pcp04414054pcs.nrockv01.md.comcast.net[69.140.185.48]) by comcast.net (sccrmhc13) with ESMTP id <2005110523192001300bf0s1e>; Sat, 5 Nov 2005 23:19:25 +0000 Message-ID: <436D3DF7.5000002@gentoo.org> Date: Sat, 05 Nov 2005 18:19:19 -0500 From: Kumba User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> In-Reply-To: <436D0061.5070100@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9428 X-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 Jim Gifford wrote: > I've been working on getting the RaQ2 to work with the current 2.6.14 > kernel, but no luck at all. The last success I had was with 2.6.12.x > series. > > I'm looking for ideas, patches or whatever to get this working again. I > know it has to do with the kernel using 32bit addressing instead of 64 > bit, but have no clue where to start. > > Here is what I get when I attempt to boot it. > > > nfs 172.16.0.1 /nfsroot boot/vmlinux-2.6.14.gz > nfs: mounted "/nfsroot" > nfs: lookup "boot" > nfs: lookup "vmlinux-2.6.14.gz" > nfs: mode <0100755> > 1349KB loaded (899KB/sec) > 001512e8 1381096t > nfs: unmounted "/nfsroot" > > execute root=/dev/nfs nfsroot=172.16.0.1:/nfsroot > console=ttyS0,115200 ip=dhcp > elf64: 00080000 - 003b901f (ffffffff.80357000) (ffffffff.80000000) > elf64: ffffffff.80080000 (80080000) 3170438t + 208794t > net: interface down > > Thanx for all your assistance. Hmm, I'm unable to boot a 64bit kernel on either IP27 or IP30 here. Appears to die very early in the kernel code. It looks like your kernel also dies before doing anything meaningful, so I wonder if this is some common thing. --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 anemo@mba.ocn.ne.jp Sun Nov 6 14:58:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Nov 2005 14:58:33 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:34007 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133649AbVKFO6Q (ORCPT ); Sun, 6 Nov 2005 14:58:16 +0000 Received: from localhost (p6072-ipad209funabasi.chiba.ocn.ne.jp [58.88.117.72]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D69AEA7EC; Sun, 6 Nov 2005 23:59:19 +0900 (JST) Date: Sun, 06 Nov 2005 23:58:21 +0900 (JST) Message-Id: <20051106.235821.108306460.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Redefine outs[wl] for ide_outs[wl]. From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9429 X-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 Add missing bits to fix D-cache aliasing problem in the PIO IDE driver. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/mach-generic/ide.h b/include/asm-mips/mach-generic/ide.h index 9610069..550979a 100644 --- a/include/asm-mips/mach-generic/ide.h +++ b/include/asm-mips/mach-generic/ide.h @@ -168,8 +168,12 @@ static inline void __ide_mm_outsl(void _ /* ide_insw calls insw, not __ide_insw. Why? */ #undef insw #undef insl +#undef outsw +#undef outsl #define insw(port, addr, count) __ide_insw(port, addr, count) #define insl(port, addr, count) __ide_insl(port, addr, count) +#define outsw(port, addr, count) __ide_outsw(port, addr, count) +#define outsl(port, addr, count) __ide_outsl(port, addr, count) #endif /* __KERNEL__ */ From armcc2000@yahoo.com Sun Nov 6 15:22:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Nov 2005 15:22:32 +0000 (GMT) Received: from web35615.mail.mud.yahoo.com ([66.163.179.154]:1461 "HELO web35615.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133649AbVKFPWO (ORCPT ); Sun, 6 Nov 2005 15:22:14 +0000 Received: (qmail 10452 invoked by uid 60001); 6 Nov 2005 15:23:14 -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=YiojVKN+N37EOy3JSHMNIbD38zTEmWZCxYbYrgyMoW2pHRq/cTECZMweWam5Z+Y5Es96H5urlLgzbAxUpMyVoN5qn2EWTKdQkruzj39fOOlWmkRsE9SzTzBHonn9pJ/WGH9Uj3VJp2xpCDcs/vv2i85qGwIJQP56z4XB0xS+5cU= ; Message-ID: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> Received: from [66.218.47.204] by web35615.mail.mud.yahoo.com via HTTP; Sun, 06 Nov 2005 07:23:14 PST Date: Sun, 6 Nov 2005 07:23:14 -0800 (PST) From: Andre Subject: 2.6.14-git9 cobalt build fails To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: armcc2000@yahoo.com Precedence: bulk X-list: linux-mips Not sure if the cobalt support that's just gone into the mainstream kernel is even supposed to compile yet... but it doesn't ;-) I tried 2.6.14 + git9 patch from kernel.org. Note that default config was tweaked slightly (to enable IDE DMA and a network driver). ... CC arch/mips/pci/pci.o CC arch/mips/pci/ops-gt64111.o CC arch/mips/pci/fixup-cobalt.o arch/mips/pci/fixup-cobalt.c:35: error: `PCI_DEVICE_ID_MARVELL_GT64111' undeclared here (not in a function) arch/mips/pci/fixup-cobalt.c:35: error: initializer element is not constant arch/mips/pci/fixup-cobalt.c:35: error: (near initialization for `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_early_fixup.device') arch/mips/pci/fixup-cobalt.c:116: error: initializer element is not constant arch/mips/pci/fixup-cobalt.c:116: error: (near initialization for `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_fixup.device') arch/mips/pci/fixup-cobalt.c:58: error: __pci_fixup_PCI_VENDOR_ID_VIAPCI_DEVICE_ID_VIA_82C586_1qube_raq_via_bmIDE_fixup causes a section type conflict make[1]: *** [arch/mips/pci/fixup-cobalt.o] Error 1 make: *** [arch/mips/pci] Error 2 root@qube2:/usr/src/linux-2.6.14# __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From redhatter@gentoo.org Mon Nov 7 03:05:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 03:05:22 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:53136 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S3466533AbVKGDFE (ORCPT ); Mon, 7 Nov 2005 03:05:04 +0000 Received: (qmail 26130 invoked from network); 7 Nov 2005 13:06:04 +1000 Received: from beast.redhatters.home (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 7 Nov 2005 13:06:04 +1000 Message-ID: <436EC472.4060805@gentoo.org> Date: Mon, 07 Nov 2005 13:05:22 +1000 From: Stuart Longland Organization: Gentoo Foundation User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051029) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre CC: linux-mips@linux-mips.org Subject: Re: 2.6.14-git9 cobalt build fails References: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> In-Reply-To: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/~redhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDBF38D9AE605548F435E5969" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: redhatter@gentoo.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDBF38D9AE605548F435E5969 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Andre wrote: > Not sure if the cobalt support that's just gone into the mainstream > kernel is even supposed to compile yet... but it doesn't ;-) I tried > 2.6.14 + git9 patch from kernel.org. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think I see the cause. You should always use sources from Linux/MIPS git, as these are more likely to work. http://www.linux-mips.org/wiki/Git should have some useful resources. -- Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' --------------enigDBF38D9AE605548F435E5969 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDbsR1uarJ1mMmSrkRAmy4AJ9YD3kEA9cakWdvf/4rPoR/+Tj0YgCdFSXq 0EI4L/JFCjfYKaXMfJeZ0Y8= =M+PO -----END PGP SIGNATURE----- --------------enigDBF38D9AE605548F435E5969-- From yyuasa@gmail.com Mon Nov 7 04:15:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 04:16:11 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.199]:48396 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133360AbVKGEPw convert rfc822-to-8bit (ORCPT ); Mon, 7 Nov 2005 04:15:52 +0000 Received: by zproxy.gmail.com with SMTP id x7so241758nzc for ; Sun, 06 Nov 2005 20:17:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QMcGtTFrpyK0e3mCtYoQbR+w7eGNSnDuONPzROXDSo04Ppq+s871IOrWuEbidYQlei8syQXCPcj3LOBNNsvCk74XzbPtdYRRKVu63ULjaLfAS0+NEG4ae59GMSByljzTUZ2nGjEpBso0sVO1owLoiNxXhbbtFukuUbAY7hosgdg= Received: by 10.36.177.6 with SMTP id z6mr1520768nze; Sun, 06 Nov 2005 20:17:02 -0800 (PST) Received: by 10.36.24.9 with HTTP; Sun, 6 Nov 2005 20:17:01 -0800 (PST) Message-ID: <4955666b0511062017q5ea4fbc3g@mail.gmail.com> Date: Mon, 7 Nov 2005 13:17:02 +0900 From: Yoichi Yuasa To: Andre Subject: Re: 2.6.14-git9 cobalt build fails Cc: linux-mips@linux-mips.org In-Reply-To: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9432 X-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 Hi Andre, 2005/11/7, Andre : > Not sure if the cobalt support that's just gone into the mainstream > kernel is even supposed to compile yet... but it doesn't ;-) I tried > 2.6.14 + git9 patch from kernel.org. > > Note that default config was tweaked slightly (to enable IDE DMA and > a network driver). > > ... > CC arch/mips/pci/pci.o > CC arch/mips/pci/ops-gt64111.o > CC arch/mips/pci/fixup-cobalt.o > arch/mips/pci/fixup-cobalt.c:35: error: > `PCI_DEVICE_ID_MARVELL_GT64111' undeclared here (not in a function) > arch/mips/pci/fixup-cobalt.c:35: error: initializer element is not > constant > arch/mips/pci/fixup-cobalt.c:35: error: (near initialization for > `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_early_fixup.device') > arch/mips/pci/fixup-cobalt.c:116: error: initializer element is not > constant > arch/mips/pci/fixup-cobalt.c:116: error: (near initialization for > `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_fixup.device') > arch/mips/pci/fixup-cobalt.c:58: error: > __pci_fixup_PCI_VENDOR_ID_VIAPCI_DEVICE_ID_VIA_82C586_1qube_raq_via_bmIDE_fixup > causes a section type conflict > make[1]: *** [arch/mips/pci/fixup-cobalt.o] Error 1 > make: *** [arch/mips/pci] Error 2 > root@qube2:/usr/src/linux-2.6.14# > PCI_DEVICE_ID_MARVELL_GT64111 was removed from kernel.org git(I don't know why). Please add the following device ID to include/linux/pci_ids.h #define PCI_DEVICE_ID_MARVELL_GT64111 0x4146 Yoichi From geert@linux-m68k.org Mon Nov 7 08:51:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 08:52:10 +0000 (GMT) Received: from witte.sonytel.be ([80.88.33.193]:48295 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133374AbVKGIvw (ORCPT ); Mon, 7 Nov 2005 08:51:52 +0000 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 jA78r1va010783; Mon, 7 Nov 2005 09:53:01 +0100 (MET) Date: Mon, 7 Nov 2005 09:53:00 +0100 (CET) From: Geert Uytterhoeven To: Yoichi Yuasa cc: Andre , Linux/MIPS Development Subject: Re: 2.6.14-git9 cobalt build fails In-Reply-To: <4955666b0511062017q5ea4fbc3g@mail.gmail.com> Message-ID: References: <20051106152314.10450.qmail@web35615.mail.mud.yahoo.com> <4955666b0511062017q5ea4fbc3g@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9433 X-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 Mon, 7 Nov 2005, Yoichi Yuasa wrote: > 2005/11/7, Andre : > > Not sure if the cobalt support that's just gone into the mainstream > > kernel is even supposed to compile yet... but it doesn't ;-) I tried > > 2.6.14 + git9 patch from kernel.org. > > > > Note that default config was tweaked slightly (to enable IDE DMA and > > a network driver). > > > > ... > > CC arch/mips/pci/pci.o > > CC arch/mips/pci/ops-gt64111.o > > CC arch/mips/pci/fixup-cobalt.o > > arch/mips/pci/fixup-cobalt.c:35: error: > > `PCI_DEVICE_ID_MARVELL_GT64111' undeclared here (not in a function) > > arch/mips/pci/fixup-cobalt.c:35: error: initializer element is not > > constant > > arch/mips/pci/fixup-cobalt.c:35: error: (near initialization for > > `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_early_fixup.device') > > arch/mips/pci/fixup-cobalt.c:116: error: initializer element is not > > constant > > arch/mips/pci/fixup-cobalt.c:116: error: (near initialization for > > `__pci_fixup_PCI_VENDOR_ID_MARVELLPCI_DEVICE_ID_MARVELL_GT64111qube_raq_galileo_fixup.device') > > arch/mips/pci/fixup-cobalt.c:58: error: > > __pci_fixup_PCI_VENDOR_ID_VIAPCI_DEVICE_ID_VIA_82C586_1qube_raq_via_bmIDE_fixup > > causes a section type conflict > > make[1]: *** [arch/mips/pci/fixup-cobalt.o] Error 1 > > make: *** [arch/mips/pci] Error 2 > > root@qube2:/usr/src/linux-2.6.14# > > > > PCI_DEVICE_ID_MARVELL_GT64111 was removed from kernel.org git(I don't know why). All `unused' definitions were removed from pci_ids.h. Hence if fixup-cobalt.c in Linus' tree was not in sync, it was removed. 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 Nov 7 11:45:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 11:45:31 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:21258 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133606AbVKGLpN (ORCPT ); Mon, 7 Nov 2005 11:45:13 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id AC1E2E1CAD; Mon, 7 Nov 2005 12:46:17 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03446-09; Mon, 7 Nov 2005 12:46:17 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 6B687E1C98; Mon, 7 Nov 2005 12:46:17 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jA7Bk6gM031874; Mon, 7 Nov 2005 12:46:11 +0100 Date: Mon, 7 Nov 2005 11:46:20 +0000 (GMT) From: "Maciej W. Rozycki" To: Jim Gifford Cc: Linux MIPS List Subject: Re: MIPS - 64bit woes In-Reply-To: <436D0061.5070100@jg555.com> Message-ID: References: <436D0061.5070100@jg555.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1165/Sun Nov 6 06:12:58 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9434 X-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 Sat, 5 Nov 2005, Jim Gifford wrote: > I've been working on getting the RaQ2 to work with the current 2.6.14 > kernel, but no luck at all. The last success I had was with 2.6.12.x > series. > > I'm looking for ideas, patches or whatever to get this working again. I > know it has to do with the kernel using 32bit addressing instead of 64 > bit, but have no clue where to start. It must be platform-specific -- I haven't checked 2.6.14, but 64-bit 2.6.13 is good enough to boot into multi-user with the SWARM. Maciej From oski2001@hotmail.com Mon Nov 7 18:04:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 18:04:43 +0000 (GMT) Received: from bay101-dav18.bay101.hotmail.com ([64.4.56.90]:40226 "EHLO hotmail.com") by ftp.linux-mips.org with ESMTP id S8135602AbVKGSEZ (ORCPT ); Mon, 7 Nov 2005 18:04:25 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Nov 2005 10:05:37 -0800 Message-ID: Received: from 81.159.218.61 by BAY101-DAV18.phx.gbl with DAV; Mon, 07 Nov 2005 18:05:37 +0000 X-Originating-IP: [81.159.218.61] X-Originating-Email: [oski2001@hotmail.com] X-Sender: oski2001@hotmail.com From: "oski" To: Subject: Compiling a kernel for ibm z50 Date: Mon, 7 Nov 2005 18:07:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 07 Nov 2005 18:05:37.0228 (UTC) FILETIME=[DB0138C0:01C5E3C5] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: oski2001@hotmail.com Precedence: bulk X-list: linux-mips Hi, I am still having problems when compiling thfe kernel. I get an Error and the last lines are: init/do_mounts.o: In function "mount_root" do_mounts.c: (.text.init+0x7e8): undefined reference to "ip_auto_config" do_mounts.c: (.text.init+0x7e8): relocation truncated to fit:R_MIPS_26 against "ip_auto_config" make: *** (vmlinux) Error 1 Any suggestions? Many tks oski From ralf@linux-mips.org Mon Nov 7 19:30:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 19:30:29 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:5907 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133815AbVKGTaL (ORCPT ); Mon, 7 Nov 2005 19:30:11 +0000 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 jA7JVJDM016853; Mon, 7 Nov 2005 19:31:19 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA7JVIrs016852; Mon, 7 Nov 2005 19:31:18 GMT Date: Mon, 7 Nov 2005 19:31:18 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Redefine outs[wl] for ide_outs[wl]. Message-ID: <20051107193118.GC2915@linux-mips.org> References: <20051106.235821.108306460.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051106.235821.108306460.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9436 X-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 On Sun, Nov 06, 2005 at 11:58:21PM +0900, Atsushi Nemoto wrote: > Add missing bits to fix D-cache aliasing problem in the PIO IDE driver. > > Signed-off-by: Atsushi Nemoto Thanks, applied Ralf From sshtylyov@ru.mvista.com Mon Nov 7 19:55:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 19:55:39 +0000 (GMT) Received: from [85.21.88.2] ([85.21.88.2]:48013 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8135576AbVKGTzV (ORCPT ); Mon, 7 Nov 2005 19:55:21 +0000 Received: (qmail 6304 invoked from network); 7 Nov 2005 19:56:30 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 7 Nov 2005 19:56:30 -0000 Message-ID: <436FB1DE.6010405@ru.mvista.com> Date: Mon, 07 Nov 2005 22:58:22 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS Development CC: alsa-devel@lists.sourceforge.net, dan@embeddededge.com, Pete Popov , Konstantin Baidarov , Manish Lachwani Subject: Re: [Alsa-devel] Au1550 OSS driver issues References: <43452054.2090305@ru.mvista.com> In-Reply-To: <43452054.2090305@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------050909010902020204030508" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050909010902020204030508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I wrote: > We have found some issues with Au1550 AC'97 OSS driver in 2.6 > (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver > (drivers/sound/au1550_psc.c). > First, we don't think that using readl() calls instead of au_readl() is > correct -- readl() is subject to byte-swapping etc., so may not work in > BE mode anymore and au_readl() is intended for embedded Au1550 devices for > which the byte swapping issue is resolved automagically, and BTW the same > PSC_AC97STAT register is read "both ways" in the driver. ... for no apparent reason? > That's what the first patch is about. > Second, start_dac() grabs a spinlock already held by its caller, > au1550_write(). This doesn't show up with the standard UP spinlock > impelmentation but when the different one (mutex based) is in use, a > lockup happens. The second patch demonstates a possible solution but > here's a question: why there's no "symmetric" spinlock logic in > start_adc(), may be here exits another potential issue? After having a look at sound/oss/au1000.c, here's an updated patch that deals with "nested" spinlocks the same way that driver does, and adds spinlock to start_adc() as well. WBR, Sergei --------------050909010902020204030508 Content-Type: text/plain; name="au1550_ac97_readl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="au1550_ac97_readl.patch" Signed-off-by: Konstantin Baydarov Signed-off-by: Sergei Shtylyov Index: linux/sound/oss/au1550_ac97.c =================================================================== --- linux.orig/sound/oss/au1550_ac97.c +++ linux/sound/oss/au1550_ac97.c @@ -463,7 +463,7 @@ stop_dac(struct au1550_state *s) /* Wait for Transmit Busy to show disabled. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_TB) != 0); @@ -492,7 +492,7 @@ stop_adc(struct au1550_state *s) /* Wait for Receive Busy to show disabled. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_RB) != 0); @@ -542,7 +542,7 @@ set_xmit_slots(int num_channels) /* Wait for Device ready. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_DR) == 0); } @@ -574,7 +574,7 @@ set_recv_slots(int num_channels) /* Wait for Device ready. */ do { - stat = readl((void *)PSC_AC97STAT); + stat = au_readl(PSC_AC97STAT); au_sync(); } while ((stat & PSC_AC97STAT_DR) == 0); } @@ -1989,7 +1989,7 @@ au1550_probe(void) /* Wait for PSC ready. */ do { - val = readl((void *)PSC_AC97STAT); + val = au_readl(PSC_AC97STAT); au_sync(); } while ((val & PSC_AC97STAT_SR) == 0); @@ -2012,7 +2012,7 @@ au1550_probe(void) /* Wait for Device ready. */ do { - val = readl((void *)PSC_AC97STAT); + val = au_readl(PSC_AC97STAT); au_sync(); } while ((val & PSC_AC97STAT_DR) == 0); --------------050909010902020204030508 Content-Type: text/plain; name="au1550_ac7-spinlocks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="au1550_ac7-spinlocks.patch" Signed-off-by: Sergei Shtylyov Index: sound/oss/au1550_ac97.c =================================================================== --- sound/oss/au1550_ac97.c~ 10 Jul 2005 10:29:03 -0000 +++ sound/oss/au1550_ac97.c 7 Nov 2005 18:14:59 -0000 @@ -607,11 +607,14 @@ static void start_adc(struct au1550_state *s) { struct dmabuf *db = &s->dma_adc; + unsigned long flags; int i; if (!db->stopped) return; + spin_lock_irqsave(&s->lock, flags); + /* Put two buffers on the ring to get things started. */ for (i=0; i<2; i++) { @@ -630,6 +633,8 @@ start_adc(struct au1550_state *s) au_sync(); db->stopped = 0; + + spin_unlock_irqrestore(&s->lock, flags); } static int @@ -1181,8 +1186,11 @@ au1550_write(struct file *file, const ch if (db->nextOut >= db->rawbuf + db->dmasize) db->nextOut -= db->dmasize; db->total_bytes += db->dma_fragsize; - if (db->dma_qcount == 0) + if (db->dma_qcount == 0) { + spin_unlock(&s->lock); start_dac(s); + spin_lock(&s->lock); + } db->dma_qcount++; } spin_unlock_irqrestore(&s->lock, flags); --------------050909010902020204030508-- From sshtylyov@ru.mvista.com Mon Nov 7 20:13:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 20:13:49 +0000 (GMT) Received: from [85.21.88.2] ([85.21.88.2]:45967 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133824AbVKGUNb (ORCPT ); Mon, 7 Nov 2005 20:13:31 +0000 Received: (qmail 6515 invoked from network); 7 Nov 2005 20:14:44 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 7 Nov 2005 20:14:44 -0000 Message-ID: <436FB625.2000302@ru.mvista.com> Date: Mon, 07 Nov 2005 23:16:37 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS Development CC: Manish Lachwani , Pete Popov , Konstantin Baidarov Subject: [PATCH] arch/mips/au1000/time.c cleanup Content-Type: multipart/mixed; boundary="------------050507000808090606070305" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------050507000808090606070305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Mark au1xxx_timer_setup() __init, just because it is. Get rid of unneeded extrns (note that (*do_gettimeoffset)() is already declared by ) and an unused variable. Kill some whitespace... WBR, Sergei --------------050507000808090606070305 Content-Type: text/plain; name="Au1xx0-time-cleanup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1xx0-time-cleanup.patch" Signed-off-by: Sergei Shtylyov Index: arch/mips/au1000/common/time.c =================================================================== --- arch/mips/au1000/common/time.c~ 19 Jul 2005 07:05:36 -0000 +++ arch/mips/au1000/common/time.c 1 Nov 2005 19:03:51 -0000 @@ -50,10 +50,6 @@ #include #include -extern void do_softirq(void); -extern volatile unsigned long wall_jiffies; -unsigned long missed_heart_beats = 0; - static unsigned long r4k_offset; /* Amount to increment compare reg each time */ static unsigned long r4k_cur; /* What counter should be at next timer irq */ int no_au1xxx_32khz; @@ -387,10 +383,9 @@ static unsigned long do_fast_pm_gettimeo } #endif -void au1xxx_timer_setup(struct irqaction *irq) +void __init au1xxx_timer_setup(struct irqaction *irq) { - unsigned int est_freq; - extern unsigned long (*do_gettimeoffset)(void); + unsigned int est_freq; printk("calculating r4koff... "); r4k_offset = cal_r4koff(); --------------050507000808090606070305-- From rlrevell@joe-job.com Mon Nov 7 20:19:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 20:20:06 +0000 (GMT) Received: from mustang.oldcity.dca.net ([216.158.38.3]:42721 "HELO mustang.oldcity.dca.net") by ftp.linux-mips.org with SMTP id S8135578AbVKGUTr (ORCPT ); Mon, 7 Nov 2005 20:19:47 +0000 Received: (qmail 21909 invoked from network); 7 Nov 2005 20:20:59 -0000 Received: from unknown (HELO ?192.168.0.20?) (206.105.184.167) by mustang with SMTP; 7 Nov 2005 20:20:59 -0000 Subject: Re: [Alsa-devel] Au1550 OSS driver issues From: Lee Revell To: Sergei Shtylylov Cc: Linux MIPS Development , alsa-devel@lists.sourceforge.net, dan@embeddededge.com, Pete Popov , Konstantin Baidarov , Manish Lachwani In-Reply-To: <436FB1DE.6010405@ru.mvista.com> References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> Content-Type: text/plain Date: Mon, 07 Nov 2005 15:19:14 -0500 Message-Id: <1131394755.8383.92.camel@mindpipe> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rlrevell@joe-job.com Precedence: bulk X-list: linux-mips On Mon, 2005-11-07 at 22:58 +0300, Sergei Shtylylov wrote: > After having a look at sound/oss/au1000.c, here's an updated patch > that deals with "nested" spinlocks the same way that driver does, and adds > spinlock to start_adc() as well. The OSS drivers are scheduled for removal, it's unlikely that this will be accepted into the kernel. It also has nothing to do with ALSA. Lee From maillist@jg555.com Mon Nov 7 22:21:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 22:21:55 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:26542 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8135586AbVKGWV2 (ORCPT ); Mon, 7 Nov 2005 22:21:28 +0000 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, 07 Nov 2005 14:22:41 -0800 id 0022907D.436FD3B1.00000139 Message-ID: <436FD396.9080807@jg555.com> Date: Mon, 07 Nov 2005 14:22:14 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumba CC: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <436D3DF7.5000002@gentoo.org> In-Reply-To: <436D3DF7.5000002@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9440 X-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 I've talked to a few others, who are having similar issues also Kumba, I made a diff of 2.6.12 and 2.6.14, trying to figure out what's causing this. Looks like some major rewrites have occured in some areas. If anyone would like to view the diff I have it on my website, http://ftp.jg555.com/mips_diff.txt -- ---- Jim Gifford maillist@jg555.com From yuasa@hh.iij4u.or.jp Mon Nov 7 22:29:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Nov 2005 22:30:13 +0000 (GMT) Received: from mo01.iij4u.or.jp ([210.130.0.20]:10967 "EHLO mo01.iij4u.or.jp") by ftp.linux-mips.org with ESMTP id S8135588AbVKGW34 (ORCPT ); Mon, 7 Nov 2005 22:29:56 +0000 Received: MO(mo01)id jA7MV7sf015389; Tue, 8 Nov 2005 07:31:07 +0900 (JST) Received: MDO(mdo01) id jA7MV6q7022663; Tue, 8 Nov 2005 07:31:07 +0900 (JST) Received: from stratos (h057.p117.iij4u.or.jp [210.130.117.57]) by mbox.iij4u.or.jp (4U-MR/mbox01) id jA7MV5ed017155 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Nov 2005 07:31:06 +0900 (JST) Date: Tue, 8 Nov 2005 07:31:05 +0900 From: Yoichi Yuasa To: "oski" Cc: linux-mips@linux-mips.org Subject: Re: Compiling a kernel for ibm z50 Message-Id: <20051108073105.468cd5f4.yuasa@hh.iij4u.or.jp> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9441 X-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 Hi, On Mon, 7 Nov 2005 18:07:42 -0000 "oski" wrote: > Hi, > I am still having problems when compiling thfe kernel. > I get an Error and the last lines are: > init/do_mounts.o: In function "mount_root" > do_mounts.c: (.text.init+0x7e8): undefined reference to "ip_auto_config" > do_mounts.c: (.text.init+0x7e8): relocation truncated to fit:R_MIPS_26 > against "ip_auto_config" > make: *** (vmlinux) Error 1 > > Any suggestions? Which kernel version do you use? Yoichi From kumba@gentoo.org Tue Nov 8 00:50:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 00:50:58 +0000 (GMT) Received: from rwcrmhc14.comcast.net ([204.127.198.54]:45795 "EHLO rwcrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8133832AbVKHAul (ORCPT ); Tue, 8 Nov 2005 00:50:41 +0000 Received: from [192.168.1.15] (pcp04414054pcs.nrockv01.md.comcast.net[69.140.185.48]) by comcast.net (rwcrmhc14) with ESMTP id <20051108005124014006gp59e>; Tue, 8 Nov 2005 00:51:24 +0000 Message-ID: <436FF689.3010308@gentoo.org> Date: Mon, 07 Nov 2005 19:51:21 -0500 From: Kumba User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9442 X-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 Maciej W. Rozycki wrote: > > It must be platform-specific -- I haven't checked 2.6.14, but 64-bit > 2.6.13 is good enough to boot into multi-user with the SWARM. 2.6.13.4 works on all systems I can test (O2, Octane, Origin*, Indy, I2 Impact), but for me, it appears 2.6.14 dies very early in kernel initialization on both Octane and Origin. I have yet to try another, like O2, but I'm going to do that shortly in the hopes O2 may initialize an output device and give me an idea of what's going on. * 2.6.13.4 Works on Origin, but can't allocate PCI resources for the scsi properly. 2.6.12.5 is what works best for this system. --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 anderson@netsweng.com Tue Nov 8 01:40:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 01:40:51 +0000 (GMT) Received: from grayson.netsweng.com ([207.235.77.11]:52968 "EHLO grayson.netsweng.com") by ftp.linux-mips.org with ESMTP id S8135590AbVKHBk1 (ORCPT ); Tue, 8 Nov 2005 01:40:27 +0000 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1EZIUV-0003LC-00 for ; Mon, 07 Nov 2005 20:41:39 -0500 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12653-03 for ; Mon, 7 Nov 2005 20:41:30 -0500 (EST) Received: from h168.98.28.71.ip.alltel.net ([71.28.98.168] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1EZIUM-0003L0-00 for ; Mon, 07 Nov 2005 20:41:30 -0500 Date: Mon, 7 Nov 2005 20:41:28 -0500 (EST) From: Stuart Anderson X-X-Sender: anderson@trantor.stuart.netsweng.com To: Linux MIPS List Subject: Re: MIPS - 64bit woes In-Reply-To: <436FD396.9080807@jg555.com> Message-ID: References: <436D0061.5070100@jg555.com> <436D3DF7.5000002@gentoo.org> <436FD396.9080807@jg555.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netsweng.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anderson@netsweng.com Precedence: bulk X-list: linux-mips On Mon, 7 Nov 2005, Jim Gifford wrote: > I've talked to a few others, who are having similar issues also Kumba, I made > a diff of 2.6.12 and 2.6.14, trying to figure out what's causing this. Looks > like some major rewrites have occured in some areas. I have a 2.6.14-rc1 kernel that works great, and when I tried 2.6.14-rc2, it would have up on boot. In my case, I'm using NFS root, and the networking would just go away when the system got busy. This would cause the nfsroot to hang, and then any process that touched a file would hang. It sort of felt like interrupts stopped working, but I was not able to verify that. It seems that a serial console continued to work, so it doesn't seem like all interrupts stopped working. I have backported nearly all of the relevent arch/mips files to my 2.6.14-rc1 tree, and everything is still happy, so I'm inclined to think it might not be something inside arch/mips. I've stared at the diffs between rc1 and rc2 until I'm corss-eyed, but nothing has jumped out at me as being obviously broken. Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From n_tbinh@yahoo.com Tue Nov 8 07:01:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 07:02:15 +0000 (GMT) Received: from web30703.mail.mud.yahoo.com ([68.142.200.136]:27760 "HELO web30703.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133364AbVKHHB4 (ORCPT ); Tue, 8 Nov 2005 07:01:56 +0000 Received: (qmail 42613 invoked by uid 60001); 8 Nov 2005 07:03:06 -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=bymjyddgbjOQTKLhJLew7a/Uvyqe/vbcfjPnkyAFLVNqUiwbTGA4cp8rwyce/az+Qou8WE8+/n4Npd9Q+2pkcM3w+10MMy8el0fkh2c1VPHEvhoMkmebL3xC/g+szJFnUF3YsP6ET+t6KunElOsG6GR+EHV/OeNmGxh3V6rb9EA= ; Message-ID: <20051108070306.42611.qmail@web30703.mail.mud.yahoo.com> Received: from [203.190.168.9] by web30703.mail.mud.yahoo.com via HTTP; Tue, 08 Nov 2005 07:03:06 GMT Date: Tue, 8 Nov 2005 07:03:06 +0000 (GMT) From: Nguyen Thanh Binh Subject: Re: Booting with NFS fails To: Manish Lachwani , linux-mips@linux-mips.org Cc: mlachwani@mvista.com In-Reply-To: <20051105090852.27444.qmail@web30904.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: n_tbinh@yahoo.com Precedence: bulk X-list: linux-mips Hi, I do not know if you could receive the complete boot log. I am resending that as follows: ==================================================== loaded at: 00400000 004A01E4 board data at: 0049D13C 0049D154 relocated to: 00405650 00405668 zimage at: 00405C1B 0049C4F1 avail ram: 004A1000 04000000 Linux/PPC load: console=ttyS0,9600 ip=on nfsroot=192.168.114.27:/home/memec/MyDwUncompressing Linux...done. Now booting the kernel Linux version 2.4.20_mvl31-ml300 (memec@TTT) (gcc version 3.3.1 (MontaVista 3.35Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc. (source@mvista.com)On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 ip=on nfsroot=192.168.114.27:/home/memewXilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000 Calibrating delay loop... 97.48 BogoMIPS Memory: 63264k available (1068k kernel code, 368k data, 60k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket OCP uart ver 1.6.2 init complete LSP Revision 42 ikconfig 0.5 with /proc/ikconfig Starting kswapd Disabling the Out Of Memory Killer devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0xfdfff003 (irq = 26) is a 16450 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) eth0: using fifo mode. eth0: Xilinx EMAC #0 at 0x80400000 mapped to 0xC500D000, irq=31 eth0: id 2.0a; block id 0, type 8 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) Sending DHCP requests ., OK IP-Config: Got DHCP answer from 192.168.114.27, my address is 192.168.114.30 IP-Config: Complete: device=eth0, addr=192.168.114.30, mask=255.255.255.0, gw=192.168.114.27, host=192.168.114.30, domain=, nis-domain=(none), bootserver=192.168.114.27, rootserver=192.168.114.27, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 192.168.114.27 Looking up port of RPC 100005/1 on 192.168.114.27 eth0: Link carrier lost. VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 60k init eth0: Could not read PHY status register; error 1003 eth0: Terminating link monitoring. ==================================================== Thank you for your help. Nguyen Binh --- Manish Lachwani wrote: > Can you please post the complete boot log? > > Thanks > Manish Lachwani > > --- Nguyen Thanh Binh wrote: > > > Hello all, > > > > I have installed Red Hat Enterprise 3 on the host > > (x86) and MontaVista Linux (previewkit) on the > > target > > (memec virtex-4 Fx12 LC board). When booting the > > target using NFS from the host, the following > error > > appeared: > > > > eth0: Link carrier lost. > > eth0: Could not read PHY control register; > error > > 1003 > > eth0: Terminating link monitoring. > > > > It is very strange, because ethernet does not work > > as > > the error shows but I can ping the target from the > > host with the IP got with DHCP. > > > > Your help or experience would be appreciated. > > > > Thank you. > > > > Nguyen Binh > > > > > > > > > > > ___________________________________________________________ > > > > How much free photo storage do you get? Store your > > holiday > > snaps for FREE with Yahoo! Photos > > http://uk.photos.yahoo.com > > > > > > > Nguyễn Thanh Bình ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From vagabon.xyz@gmail.com Tue Nov 8 10:48:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 10:48:52 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.201]:55235 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8135811AbVKHKse convert rfc822-to-8bit (ORCPT ); Tue, 8 Nov 2005 10:48:34 +0000 Received: by zproxy.gmail.com with SMTP id l8so502514nzf for ; Tue, 08 Nov 2005 02:49:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lhqEyAMSgcpJbveFu1bguGsCYhuSc1ENgHSLNOInZ11Uq2K1UJlNeq3pe3jQSDLKCc4q6RBbxE1Pz4ohS88Xq1i5qUyvz01TAahxCp3aKIFUDv9PE+14bPQgATPeN1gpCJ4F8HJ9Q+HKBvn2W12aztqY4Qu8rIZ1V2duf8U1ims= Received: by 10.36.101.3 with SMTP id y3mr2279372nzb; Tue, 08 Nov 2005 02:49:48 -0800 (PST) Received: by 10.36.47.8 with HTTP; Tue, 8 Nov 2005 02:49:48 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2005 11:49:48 +0100 From: Franck To: linux-mips@linux-mips.org Subject: git and tags... MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi, I'm trying to retrieve a linux kernel by tag using git. Let's say for example I want my working tree to be a linux 2.6.12 copy from git repository. How can I do that ? I tried these commands but it seems that there's no tag in git repository git clone rsync://ftp.linux-mips.org/git/linux.git linux.git git pull http://www.linux-mips.org/pub/scm/linux.git tag linux_2_6_12 Thanks -- Franck From ralf@linux-mips.org Tue Nov 8 11:00:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 11:00:40 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:20230 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8135810AbVKHLAX (ORCPT ); Tue, 8 Nov 2005 11:00:23 +0000 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 jA8B1Ym1006339; Tue, 8 Nov 2005 11:01:34 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA8B1YKc006338; Tue, 8 Nov 2005 11:01:34 GMT Date: Tue, 8 Nov 2005 11:01:34 +0000 From: Ralf Baechle To: Franck Cc: linux-mips@linux-mips.org Subject: Re: git and tags... Message-ID: <20051108110134.GA2689@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9446 X-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 On Tue, Nov 08, 2005 at 11:49:48AM +0100, Franck wrote: > I'm trying to retrieve a linux kernel by tag using git. Let's say for > example I want my working tree to be a linux 2.6.12 copy from git > repository. How can I do that ? > > I tried these commands but it seems that there's no tag in git repository > > git clone rsync://ftp.linux-mips.org/git/linux.git linux.git > git pull http://www.linux-mips.org/pub/scm/linux.git tag linux_2_6_12 ls .git/refs/tags to see the tag names. Ralf From vagabon.xyz@gmail.com Tue Nov 8 17:23:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 17:24:10 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.199]:46408 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133862AbVKHRXu convert rfc822-to-8bit (ORCPT ); Tue, 8 Nov 2005 17:23:50 +0000 Received: by zproxy.gmail.com with SMTP id l8so583758nzf for ; Tue, 08 Nov 2005 09:25:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fAx893bhQvt/PieCkwBJQn6Go5+kb/nbs7Q5tFN2jFJysqDpDne2NMWZdzif0Xt2xZ3JZyBzWJFN0ix2tFmSyrAADqIlQwleG6waBQFHaulyUl2qwDTkXb/9zclz+tbW4LlT52RoH9AbSnznHwwGV8WnMIfEpcq4P4eFJd/JQcM= Received: by 10.36.101.3 with SMTP id y3mr2509087nzb; Tue, 08 Nov 2005 09:25:08 -0800 (PST) Received: by 10.36.47.8 with HTTP; Tue, 8 Nov 2005 09:25:06 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2005 18:25:06 +0100 From: Franck To: Ralf Baechle Subject: Re: git and tags... Cc: linux-mips@linux-mips.org In-Reply-To: <20051108110134.GA2689@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20051108110134.GA2689@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/11/8, Ralf Baechle : > On Tue, Nov 08, 2005 at 11:49:48AM +0100, Franck wrote: > > > I'm trying to retrieve a linux kernel by tag using git. Let's say for > > example I want my working tree to be a linux 2.6.12 copy from git > > repository. How can I do that ? > > > > I tried these commands but it seems that there's no tag in git repository > > > > git clone rsync://ftp.linux-mips.org/git/linux.git linux.git > > git pull http://www.linux-mips.org/pub/scm/linux.git tag linux_2_6_12 > > ls .git/refs/tags to see the tag names. > OK, so tags have been renamed into "linux-2.6.x". Why not using the same mainline name convention (v2.6.x) ? I have another question (which is the first one in my previous email), how can I make my working tree a kernel version 2.6.9 for example ? And the last question related to mips git repository, why does kernel v2.2, v2.4, v2.6 are in the same repository ? Why not seperate different major version of the kernel in a seperate repository ? Thanks -- Franck From adobriyan@gmail.com Tue Nov 8 17:29:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 17:30:14 +0000 (GMT) Received: from nproxy.gmail.com ([64.233.182.199]:30523 "EHLO nproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8135891AbVKHR3y (ORCPT ); Tue, 8 Nov 2005 17:29:54 +0000 Received: by nproxy.gmail.com with SMTP id l36so200011nfa for ; Tue, 08 Nov 2005 09:31:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=uFXdSiwcEiarq+C3uG4X0F8afpVDgA9S9XFA/aCI7sH1SnLhzAb7lJgc+IsRndeFaEs93tth+bwcUSVKelPf8186Bkf2RL5JzfeHwymau+uzMLx1KNjkOrSLBLZkAjCpWjdsMUUjI+bWPAi/rUfHIfO63F66k4Qf4O0uSBLynrc= Received: by 10.48.234.16 with SMTP id g16mr2894993nfh; Tue, 08 Nov 2005 09:31:13 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id p45sm3501590nfa.2005.11.08.09.31.11; Tue, 08 Nov 2005 09:31:13 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 8 Nov 2005 20:44:40 +0300 (MSK) Date: Tue, 8 Nov 2005 20:44:37 +0300 From: Alexey Dobriyan To: Ralf Baechle Cc: linux-mips@linux-mips.org, Andrew Morton , Clemens Buchacher Subject: [PATCH] arch/mips/au1000/common/usbdev.c: don't concatenate __FUNCTION__ with strings Message-ID: <20051108174437.GB7631@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Clemens Buchacher It's deprecated. Use "%s", __FUNCTION__ instead. Signed-off-by: Clemens Buchacher Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/arch/mips/au1000/common/usbdev.c =================================================================== --- linux-kj.orig/arch/mips/au1000/common/usbdev.c 2005-11-08 12:33:24.000000000 +0300 +++ linux-kj/arch/mips/au1000/common/usbdev.c 2005-11-08 13:10:41.000000000 +0300 @@ -348,7 +348,7 @@ endpoint_stall(endpoint_t * ep) { u32 cs; - warn(__FUNCTION__); + warn("%s", __FUNCTION__); cs = au_readl(ep->reg->ctrl_stat) | USBDEV_CS_STALL; au_writel(cs, ep->reg->ctrl_stat); @@ -360,7 +360,7 @@ endpoint_unstall(endpoint_t * ep) { u32 cs; - warn(__FUNCTION__); + warn("%s", __FUNCTION__); cs = au_readl(ep->reg->ctrl_stat) & ~USBDEV_CS_STALL; au_writel(cs, ep->reg->ctrl_stat); From adobriyan@gmail.com Tue Nov 8 17:46:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 17:47:08 +0000 (GMT) Received: from nproxy.gmail.com ([64.233.182.198]:65439 "EHLO nproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8135892AbVKHRqs (ORCPT ); Tue, 8 Nov 2005 17:46:48 +0000 Received: by nproxy.gmail.com with SMTP id l37so178055nfc for ; Tue, 08 Nov 2005 09:48:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=pgUhAJZ1jfY4pZSU9gRd1cKAe1LT2QzxO6zqByg1OTf3n1kiVGXzTtxCLDaeyTln/jKIy6XfLDxr+RKUyLdEWY75idCs4bb78m04iROhiGAMgdjkMGF3UZFnLd/pxNstEvMz4Y1jz97wCH3dhBiPXIrAisxCUHV7KRhsE8IOu0U= Received: by 10.48.157.3 with SMTP id f3mr1358898nfe; Tue, 08 Nov 2005 09:48:07 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id z73sm3608298nfb.2005.11.08.09.48.05; Tue, 08 Nov 2005 09:48:07 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 8 Nov 2005 21:01:33 +0300 (MSK) Date: Tue, 8 Nov 2005 21:01:31 +0300 From: Alexey Dobriyan To: Ralf Baechle Cc: Domen Puncer , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: [PATCH] Remove arch/mips/arc/salone.c Message-ID: <20051108180131.GF7631@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Domen Puncer ArcLoad(), ArcInvoke(), ArcExecute() aren't used. Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/arch/mips/arc/Makefile =================================================================== --- linux-kj.orig/arch/mips/arc/Makefile 2005-11-08 20:46:24.000000000 +0300 +++ linux-kj/arch/mips/arc/Makefile 2005-11-08 20:47:36.000000000 +0300 @@ -3,7 +3,7 @@ # lib-y += cmdline.o env.o file.o identify.o init.o \ - misc.o salone.o time.o tree.o + misc.o time.o tree.o lib-$(CONFIG_ARC_MEMORY) += memory.o lib-$(CONFIG_ARC_CONSOLE) += arc_con.o Index: linux-kj/arch/mips/arc/salone.c =================================================================== --- linux-kj.orig/arch/mips/arc/salone.c 2005-11-08 20:46:24.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,24 +0,0 @@ -/* - * Routines to load into memory and execute stand-along program images using - * ARCS PROM firmware. - * - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - */ -#include -#include - -LONG __init ArcLoad(CHAR *Path, ULONG TopAddr, ULONG *ExecAddr, ULONG *LowAddr) -{ - return ARC_CALL4(load, Path, TopAddr, ExecAddr, LowAddr); -} - -LONG __init ArcInvoke(ULONG ExecAddr, ULONG StackAddr, ULONG Argc, CHAR *Argv[], - CHAR *Envp[]) -{ - return ARC_CALL5(invoke, ExecAddr, StackAddr, Argc, Argv, Envp); -} - -LONG __init ArcExecute(CHAR *Path, LONG Argc, CHAR *Argv[], CHAR *Envp[]) -{ - return ARC_CALL4(exec, Path, Argc, Argv, Envp); -} From adobriyan@gmail.com Tue Nov 8 17:49:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 17:49:54 +0000 (GMT) Received: from nproxy.gmail.com ([64.233.182.199]:50803 "EHLO nproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8135892AbVKHRta (ORCPT ); Tue, 8 Nov 2005 17:49:30 +0000 Received: by nproxy.gmail.com with SMTP id l36so201507nfa for ; Tue, 08 Nov 2005 09:50:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=NZJ8dU6Sbh5fBCi0Z8gSwu6ALdlpJeI+6W5HXLX8/M1E0wDFRTMYN8EdRD0Eh6n8k7xJwnNkMPPIXrN14zC8XDwjZIOQO7KvUmdYpVXMnTVa51j8eTDvmgC0ZcdJYKKCwp3k+kV3N2DLKNXChL6MJ2nsNroe2DbKsFr4DQh6qx4= Received: by 10.48.229.12 with SMTP id b12mr1906742nfh; Tue, 08 Nov 2005 09:50:49 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id c28sm291831nfb.2005.11.08.09.50.47; Tue, 08 Nov 2005 09:50:49 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 8 Nov 2005 21:04:15 +0300 (MSK) Date: Tue, 8 Nov 2005 21:04:13 +0300 From: Alexey Dobriyan To: Ralf Baechle Cc: Domen Puncer , linux-mips@linux-mips.org, Andrew Morton Subject: [PATCH] Remove arch/mips/pmc-sierra/yosemite/ht-irq.c Message-ID: <20051108180413.GG7631@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Domen Puncer Remove nowhere referenced file ("grep ht-irq -r ." didn't find anything). Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/arch/mips/pmc-sierra/yosemite/ht-irq.c =================================================================== --- linux-kj.orig/arch/mips/pmc-sierra/yosemite/ht-irq.c 2005-11-08 20:46:25.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,52 +0,0 @@ -/* - * Copyright 2003 PMC-Sierra - * Author: Manish Lachwani (lachwani@pmc-sierra.com) - * - * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * 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., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#include -#include -#include -#include -#include - -/* - * HT Bus fixup for the Titan - * XXX IRQ values need to change based on the board layout - */ -void __init titan_ht_pcibios_fixup_bus(struct pci_bus *bus) -{ - struct pci_bus *current_bus = bus; - struct pci_dev *devices; - struct list_head *devices_link; - - list_for_each(devices_link, &(current_bus->devices)) { - devices = pci_dev_b(devices_link); - if (devices == NULL) - continue; - } - - /* - * PLX and SPKT related changes go here - */ - -} From ralf@linux-mips.org Tue Nov 8 18:44:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 18:44:30 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:2584 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8135889AbVKHSoN (ORCPT ); Tue, 8 Nov 2005 18:44:13 +0000 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 jA8IjMbk012127; Tue, 8 Nov 2005 18:45:22 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA8IjL7p012119; Tue, 8 Nov 2005 18:45:22 GMT Date: Tue, 8 Nov 2005 18:45:21 +0000 From: Ralf Baechle To: Franck Cc: linux-mips@linux-mips.org Subject: Re: git and tags... Message-ID: <20051108184521.GB2689@linux-mips.org> References: <20051108110134.GA2689@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9451 X-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 On Tue, Nov 08, 2005 at 06:25:06PM +0100, Franck wrote: > OK, so tags have been renamed into "linux-2.6.x". Why not using the > same mainline name convention (v2.6.x) ? The same reason that some people like blue and others prefer green ;-) > I have another question (which is the first one in my previous email), > how can I make my working tree a kernel version 2.6.9 for example ? git-read-tree $(cat .git/refs/tags/linux-2.6.9) git-checkout-index -f -a -u -q > And the last question related to mips git repository, why does kernel > v2.2, v2.4, v2.6 are in the same repository ? Why not seperate > different major version of the kernel in a seperate repository ? The extra space consumption for all these historic versions in a compressed git repository is extremly little. Ralf From anderson@netsweng.com Tue Nov 8 20:48:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 20:48:58 +0000 (GMT) Received: from grayson.netsweng.com ([207.235.77.11]:30377 "EHLO grayson.netsweng.com") by ftp.linux-mips.org with ESMTP id S8135896AbVKHUsj (ORCPT ); Tue, 8 Nov 2005 20:48:39 +0000 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1EZaPm-0006uV-00 for ; Tue, 08 Nov 2005 15:49:58 -0500 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26480-02 for ; Tue, 8 Nov 2005 15:49:49 -0500 (EST) Received: from h168.98.28.71.ip.alltel.net ([71.28.98.168] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1EZaPa-0006uR-00 for ; Tue, 08 Nov 2005 15:49:47 -0500 Date: Tue, 8 Nov 2005 15:49:45 -0500 (EST) From: Stuart Anderson X-X-Sender: anderson@trantor.stuart.netsweng.com To: linux-mips@linux-mips.org Subject: Re: Booting with NFS fails In-Reply-To: <20051108070306.42611.qmail@web30703.mail.mud.yahoo.com> Message-ID: References: <20051108070306.42611.qmail@web30703.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netsweng.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anderson@netsweng.com Precedence: bulk X-list: linux-mips This looks consistant with the problem I have been seeing as well. On Tue, 8 Nov 2005, Nguyen Thanh Binh wrote: > Hi, > > I do not know if you could receive the complete boot > log. I am resending that as follows: > > ==================================================== > loaded at: 00400000 004A01E4 > board data at: 0049D13C 0049D154 > relocated to: 00405650 00405668 > zimage at: 00405C1B 0049C4F1 > avail ram: 004A1000 04000000 > > > Linux/PPC load: console=ttyS0,9600 ip=on > nfsroot=192.168.114.27:/home/memec/MyDwUncompressing . . . > Sending DHCP requests ., OK > IP-Config: Got DHCP answer from 192.168.114.27, my > address is 192.168.114.30 > IP-Config: Complete: > device=eth0, addr=192.168.114.30, > mask=255.255.255.0, gw=192.168.114.27, > host=192.168.114.30, domain=, nis-domain=(none), > bootserver=192.168.114.27, > rootserver=192.168.114.27, rootpath= > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Looking up port of RPC 100003/2 on 192.168.114.27 > Looking up port of RPC 100005/1 on 192.168.114.27 > eth0: Link carrier lost. > VFS: Mounted root (nfs filesystem). > Mounted devfs on /dev > Freeing unused kernel memory: 60k init > eth0: Could not read PHY status register; error 1003 > eth0: Terminating link monitoring. > ==================================================== Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From drow@nevyn.them.org Tue Nov 8 21:29:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 21:30:03 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:50095 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S3466984AbVKHV3p (ORCPT ); Tue, 8 Nov 2005 21:29:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EZb3X-0007mE-LK; Tue, 08 Nov 2005 16:31:03 -0500 Date: Tue, 8 Nov 2005 16:31:03 -0500 From: Daniel Jacobowitz To: Ralf Baechle Cc: Franck , linux-mips@linux-mips.org Subject: Re: git and tags... Message-ID: <20051108213103.GA29835@nevyn.them.org> References: <20051108110134.GA2689@linux-mips.org> <20051108184521.GB2689@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051108184521.GB2689@linux-mips.org> User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9453 X-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 Tue, Nov 08, 2005 at 06:45:21PM +0000, Ralf Baechle wrote: > On Tue, Nov 08, 2005 at 06:25:06PM +0100, Franck wrote: > > > OK, so tags have been renamed into "linux-2.6.x". Why not using the > > same mainline name convention (v2.6.x) ? > > The same reason that some people like blue and others prefer green ;-) > > > I have another question (which is the first one in my previous email), > > how can I make my working tree a kernel version 2.6.9 for example ? > > git-read-tree $(cat .git/refs/tags/linux-2.6.9) > git-checkout-index -f -a -u -q IIUC, this is just "git checkout linux-2.6.9" nowadays. -- Daniel Jacobowitz CodeSourcery, LLC From a.othieno@bluewin.ch Tue Nov 8 23:26:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Nov 2005 23:26:48 +0000 (GMT) Received: from mail21.bluewin.ch ([195.186.18.66]:23458 "EHLO mail21.bluewin.ch") by ftp.linux-mips.org with ESMTP id S8135891AbVKHX0a (ORCPT ); Tue, 8 Nov 2005 23:26:30 +0000 Received: from localhost.localdomain (83.79.73.183) by mail21.bluewin.ch (Bluewin 7.2.068.1) id 435F9851002C7BDE; Tue, 8 Nov 2005 23:27:43 +0000 Received: by localhost.localdomain (Postfix, from userid 1000) id 9C3CAFE93; Tue, 8 Nov 2005 18:27:36 -0500 (EST) Date: Tue, 8 Nov 2005 18:27:36 -0500 To: Alexey Dobriyan Cc: Ralf Baechle , Domen Puncer , linux-mips@linux-mips.org, Andrew Morton Subject: Re: [PATCH] Remove arch/mips/pmc-sierra/yosemite/ht-irq.c Message-ID: <20051108232736.GA20359@krypton> References: <20051108180413.GG7631@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051108180413.GG7631@mipter.zuzino.mipt.ru> User-Agent: Mutt/1.5.9i From: a.othieno@bluewin.ch (Arthur Othieno) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: a.othieno@bluewin.ch Precedence: bulk X-list: linux-mips On Tue, Nov 08, 2005 at 09:04:13PM +0300, Alexey Dobriyan wrote: > From: Domen Puncer > > Remove nowhere referenced file ("grep ht-irq -r ." didn't find anything). And arch/mips/pmc-sierra/yosemite/ht.c, apparently.. > Signed-off-by: Domen Puncer > Signed-off-by: Alexey Dobriyan > > Index: linux-kj/arch/mips/pmc-sierra/yosemite/ht-irq.c > =================================================================== > --- linux-kj.orig/arch/mips/pmc-sierra/yosemite/ht-irq.c 2005-11-08 20:46:25.000000000 +0300 > +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 > @@ -1,52 +0,0 @@ > -/* > - * Copyright 2003 PMC-Sierra > - * Author: Manish Lachwani (lachwani@pmc-sierra.com) > - * > - * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED > - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN > - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF > - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON > - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > - * > - * 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., > - * 675 Mass Ave, Cambridge, MA 02139, USA. > - */ > - > -#include > -#include > -#include > -#include > -#include > - > -/* > - * HT Bus fixup for the Titan > - * XXX IRQ values need to change based on the board layout > - */ > -void __init titan_ht_pcibios_fixup_bus(struct pci_bus *bus) > -{ > - struct pci_bus *current_bus = bus; > - struct pci_dev *devices; > - struct list_head *devices_link; > - > - list_for_each(devices_link, &(current_bus->devices)) { > - devices = pci_dev_b(devices_link); > - if (devices == NULL) > - continue; > - } > - > - /* > - * PLX and SPKT related changes go here > - */ > - > -} arch/mips/pmc-sierra/yosemite/ht.c:418: titan_ht_pcibios_fixup_bus(c); From maillist@jg555.com Wed Nov 9 08:50:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 08:50:38 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:57015 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S3467015AbVKIIuU (ORCPT ); Wed, 9 Nov 2005 08:50:20 +0000 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; Wed, 09 Nov 2005 00:51:40 -0800 id 002AC014.4371B89C.0000205F Message-ID: <4371B87A.9040101@jg555.com> Date: Wed, 09 Nov 2005 00:51:06 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9455 X-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 Here is what I did to track down the errors. I created a diff between the last working kernel 2.6.12 and the current kernel. Started with cpu-probe.c, that to me seemed the logical choice. After patching the rest of files needed to support the patch in cpu-probe.c, I was finally able to produce a kernel under 2.6.12 with the same problem. The files that I ported from 2.6.14 to 2.6.12 are the following cpu-probe.c cpu.h mipsregs.h cache.c cpu-features.h Here is a link to the patches I used http://ftp.jg555.com/errors Looking at mipsregs.h, something doesn't look right for a 64 bit system. But I'm not the expert. Here are my findings, I hope someone out there has an idea. -- ---- Jim Gifford maillist@jg555.com From vagabon.xyz@gmail.com Wed Nov 9 09:13:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 09:14:05 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.194]:14399 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133430AbVKIJNo convert rfc822-to-8bit (ORCPT ); Wed, 9 Nov 2005 09:13:44 +0000 Received: by zproxy.gmail.com with SMTP id l8so120274nzf for ; Wed, 09 Nov 2005 01:15:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QOMqbZkvwGj7HpA4qDpH/fQmIMreowiBQxU1nNFZaOvSe2N8YQQNJhEGS6xJvfqqCtXtrI9BtFrCegnEoCHElxuXghICVN7Y1BH+gRKkcSLHlkivXRZQC2ucwqGq/+AiR6NT4N0ajemDsIcEVdbQmU+I2boS+Z2vxqjQGmJ/Z9Q= Received: by 10.37.14.30 with SMTP id r30mr313733nzi; Wed, 09 Nov 2005 01:15:07 -0800 (PST) Received: by 10.36.47.8 with HTTP; Wed, 9 Nov 2005 01:15:07 -0800 (PST) Message-ID: Date: Wed, 9 Nov 2005 10:15:07 +0100 From: Franck To: Ralf Baechle Subject: Re: git and tags... Cc: linux-mips@linux-mips.org In-Reply-To: <20051108184521.GB2689@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20051108110134.GA2689@linux-mips.org> <20051108184521.GB2689@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/11/8, Ralf Baechle : > On Tue, Nov 08, 2005 at 06:25:06PM +0100, Franck wrote: > > > OK, so tags have been renamed into "linux-2.6.x". Why not using the > > same mainline name convention (v2.6.x) ? > > The same reason that some people like blue and others prefer green ;-) > yet, mips branch follows mainline coding style...Actually it's just more convenient to remember only one tag name convention. Anyways.... > > I have another question (which is the first one in my previous email), > > how can I make my working tree a kernel version 2.6.9 for example ? > > git-read-tree $(cat .git/refs/tags/linux-2.6.9) > git-checkout-index -f -a -u -q > thanks for that > > And the last question related to mips git repository, why does kernel > > v2.2, v2.4, v2.6 are in the same repository ? Why not seperate > > different major version of the kernel in a seperate repository ? > > The extra space consumption for all these historic versions in a > compressed git repository is extremly little. > hmm...still I get: # du linux-mips.git/.git 263M # du linux-mainline.git/.git 104M Thanks -- Franck From vagabon.xyz@gmail.com Wed Nov 9 09:42:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 09:42:44 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.203]:25349 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133467AbVKIJmI convert rfc822-to-8bit (ORCPT ); Wed, 9 Nov 2005 09:42:08 +0000 Received: by zproxy.gmail.com with SMTP id l8so124679nzf for ; Wed, 09 Nov 2005 01:43:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z2OWVqo5FjYcyYRPLc5PqeNd/dsaR/67sOpCaW6Q6KgCWpX02R7SFfIu6xjePXZDCTi7a7ypV9HFvoovoMeBGW5dmn14cvV02J1727RJpJm0uooVomXaWFsroha2iLuZdKMArZ0dTuOPEZ8E1UmZIyhtXZt4sFJzL0cOcuy9RyE= Received: by 10.36.33.17 with SMTP id g17mr327318nzg; Wed, 09 Nov 2005 01:43:31 -0800 (PST) Received: by 10.36.47.8 with HTTP; Wed, 9 Nov 2005 01:43:31 -0800 (PST) Message-ID: Date: Wed, 9 Nov 2005 10:43:31 +0100 From: Franck To: Daniel Jacobowitz Subject: Re: git and tags... Cc: Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: <20051108213103.GA29835@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20051108110134.GA2689@linux-mips.org> <20051108184521.GB2689@linux-mips.org> <20051108213103.GA29835@nevyn.them.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2005/11/8, Daniel Jacobowitz : > On Tue, Nov 08, 2005 at 06:45:21PM +0000, Ralf Baechle wrote: > > On Tue, Nov 08, 2005 at 06:25:06PM +0100, Franck wrote: > > > > > OK, so tags have been renamed into "linux-2.6.x". Why not using the > > > same mainline name convention (v2.6.x) ? > > > > The same reason that some people like blue and others prefer green ;-) > > > > > I have another question (which is the first one in my previous email), > > > how can I make my working tree a kernel version 2.6.9 for example ? > > > > git-read-tree $(cat .git/refs/tags/linux-2.6.9) > > git-checkout-index -f -a -u -q > > IIUC, this is just "git checkout linux-2.6.9" nowadays. > "checkout" command seems to work with branch, not tag. Which version of git are you using ? Thanks -- Franck From ralf@linux-mips.org Wed Nov 9 10:32:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 10:32:53 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:38421 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133467AbVKIKcf (ORCPT ); Wed, 9 Nov 2005 10:32:35 +0000 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 jA9AXmVP014388; Wed, 9 Nov 2005 10:33:53 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jA8M3mVb003256; Tue, 8 Nov 2005 22:03:48 GMT Date: Tue, 8 Nov 2005 22:03:48 +0000 From: Ralf Baechle To: Alexey Dobriyan Cc: linux-mips@linux-mips.org, Andrew Morton , Clemens Buchacher Subject: Re: [PATCH] arch/mips/au1000/common/usbdev.c: don't concatenate __FUNCTION__ with strings Message-ID: <20051108220348.GC2735@linux-mips.org> References: <20051108174437.GB7631@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051108174437.GB7631@mipter.zuzino.mipt.ru> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9458 X-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 On Tue, Nov 08, 2005 at 08:44:37PM +0300, Alexey Dobriyan wrote: > From: Clemens Buchacher > > It's deprecated. Use "%s", __FUNCTION__ instead. Applied, Ralf From kumba@gentoo.org Wed Nov 9 13:35:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 13:35:42 +0000 (GMT) Received: from sccrmhc14.comcast.net ([63.240.77.84]:5825 "EHLO sccrmhc14.comcast.net") by ftp.linux-mips.org with ESMTP id S8133467AbVKINfX (ORCPT ); Wed, 9 Nov 2005 13:35:23 +0000 Received: from [192.168.1.15] (pcp04414054pcs.nrockv01.md.comcast.net[69.140.185.48]) by comcast.net (sccrmhc14) with ESMTP id <200511091336260140035bahe>; Wed, 9 Nov 2005 13:36:36 +0000 Message-ID: <4371FB46.1000805@gentoo.org> Date: Wed, 09 Nov 2005 08:36:06 -0500 From: Kumba User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> In-Reply-To: <4371B87A.9040101@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9459 X-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 Jim Gifford wrote: > Here is what I did to track down the errors. > > I created a diff between the last working kernel 2.6.12 and the current > kernel. Started with cpu-probe.c, that to me seemed the logical choice. > > After patching the rest of files needed to support the patch in > cpu-probe.c, I was finally able to produce a kernel under 2.6.12 with > the same problem. > > The files that I ported from 2.6.14 to 2.6.12 are the following > cpu-probe.c > cpu.h > mipsregs.h > cache.c > cpu-features.h > > Here is a link to the patches I used http://ftp.jg555.com/errors > > Looking at mipsregs.h, something doesn't look right for a 64 bit system. > But I'm not the expert. > > Here are my findings, I hope someone out there has an idea. Stanislaw pretty much figured it out last night. See the if statement in the 'void __init cpu_cache_init(void)' function in arch/mips/mm/cache.c. IP30, IP27, and cobalt didn't define the appropriate cache type in cpu-features.h, thus failed that check and panicked. I believe it's fixed in the newest IP30 patches, of which I have yet to take a look at. --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 maillist@jg555.com Wed Nov 9 17:21:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Nov 2005 17:21:48 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:32697 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8134055AbVKIRVb (ORCPT ); Wed, 9 Nov 2005 17:21:31 +0000 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; Wed, 09 Nov 2005 09:22:54 -0800 id 002AC014.4372306E.00005FF7 Message-ID: <4372304A.9080608@jg555.com> Date: Wed, 09 Nov 2005 09:22:18 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumba CC: Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> In-Reply-To: <4371FB46.1000805@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9460 X-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 Does look like it. I just checked the latest -- ---- Jim Gifford maillist@jg555.com From yuasa@hh.iij4u.or.jp Thu Nov 10 13:41:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 13:41:32 +0000 (GMT) Received: from mo01.iij4u.or.jp ([210.130.0.20]:37342 "EHLO mo01.iij4u.or.jp") by ftp.linux-mips.org with ESMTP id S3457885AbVKJNlN (ORCPT ); Thu, 10 Nov 2005 13:41:13 +0000 Received: MO(mo01)id jAADgd0f005664; Thu, 10 Nov 2005 22:42:39 +0900 (JST) Received: MDO(mdo00) id jAADgctM002449; Thu, 10 Nov 2005 22:42:39 +0900 (JST) Received: from stratos (h057.p117.iij4u.or.jp [210.130.117.57]) by mbox.iij4u.or.jp (4U-MR/mbox01) id jAADgbwi000760 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 10 Nov 2005 22:42:38 +0900 (JST) Date: Thu, 10 Nov 2005 22:42:36 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] add GT64111 PCI ID Message-Id: <20051110224236.68937a9a.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9461 X-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 Hi Ralf, Cobalt needs GT641111 PCI ID. Please apply. Yoichi Signed-off-by: Yoichi Yuasa diff -Npru -X dontdiff a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h 2005-11-10 22:02:04.000000000 +0900 +++ b/include/linux/pci_ids.h 2005-11-10 22:11:51.000000000 +0900 @@ -1393,6 +1393,7 @@ #define PCI_SUBDEVICE_ID_KEYSPAN_SX2 0x5334 #define PCI_VENDOR_ID_MARVELL 0x11ab +#define PCI_DEVICE_ID_MARVELL_GT64111 0x4146 #define PCI_DEVICE_ID_MARVELL_GT64260 0x6430 #define PCI_DEVICE_ID_MARVELL_MV64360 0x6460 #define PCI_DEVICE_ID_MARVELL_MV64460 0x6480 From yuasa@hh.iij4u.or.jp Thu Nov 10 14:02:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 14:02:54 +0000 (GMT) Received: from mo01.iij4u.or.jp ([210.130.0.20]:13026 "EHLO mo01.iij4u.or.jp") by ftp.linux-mips.org with ESMTP id S3458217AbVKJOCg (ORCPT ); Thu, 10 Nov 2005 14:02:36 +0000 Received: MO(mo01)id jAAE43d7008599; Thu, 10 Nov 2005 23:04:03 +0900 (JST) Received: MDO(mdo01) id jAAE42E4014330; Thu, 10 Nov 2005 23:04:02 +0900 (JST) Received: from stratos (h057.p117.iij4u.or.jp [210.130.117.57]) by mbox.iij4u.or.jp (4U-MR/mbox00) id jAAE41Q0005306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 10 Nov 2005 23:04:01 +0900 (JST) Date: Thu, 10 Nov 2005 23:04:00 +0900 From: Yoichi Yuasa To: "oski" Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org Subject: Re: Compiling a kernel for ibm z50 Message-Id: <20051110230400.18ec5e37.yuasa@hh.iij4u.or.jp> In-Reply-To: References: <20051108073105.468cd5f4.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9462 X-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 Hi, The latest MIPS v2.4 kernel has no problem. Please try the latest one. On Mon, 7 Nov 2005 22:53:33 -0000 "oski" wrote: > Hi, > > I am using linux-2.4.30-mipscvs-20050515. > > oski > > ----- Original Message ----- > From: "Yoichi Yuasa" > To: "oski" > Cc: > Sent: Monday, November 07, 2005 10:31 PM > Subject: Re: Compiling a kernel for ibm z50 > > > > Hi, > > > > On Mon, 7 Nov 2005 18:07:42 -0000 > > "oski" wrote: > > > > > Hi, > > > I am still having problems when compiling thfe kernel. > > > I get an Error and the last lines are: > > > init/do_mounts.o: In function "mount_root" > > > do_mounts.c: (.text.init+0x7e8): undefined reference to "ip_auto_config" > > > do_mounts.c: (.text.init+0x7e8): relocation truncated to fit:R_MIPS_26 > > > against "ip_auto_config" > > > make: *** (vmlinux) Error 1 > > > > > > Any suggestions? > > > > Which kernel version do you use? > > > > Yoichi > > > > > From ralf@linux-mips.org Thu Nov 10 14:18:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 14:18:56 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:36383 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3458461AbVKJOSf (ORCPT ); Thu, 10 Nov 2005 14:18:35 +0000 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 jAAEK1tE023085; Thu, 10 Nov 2005 14:20:01 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAAEJvIf023084; Thu, 10 Nov 2005 14:19:57 GMT Date: Thu, 10 Nov 2005 14:19:57 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH] add GT64111 PCI ID Message-ID: <20051110141956.GL2735@linux-mips.org> References: <20051110224236.68937a9a.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051110224236.68937a9a.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9463 X-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 On Thu, Nov 10, 2005 at 10:42:36PM +0900, Yoichi Yuasa wrote: > Hi Ralf, > > Cobalt needs GT641111 PCI ID. > Please apply. Thanks, applied. And that's not the only PCI ID which recently got axed ... Ralf From matej.kupljen@ultra.si Thu Nov 10 14:51:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 14:51:33 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:1249 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S3458490AbVKJOvQ (ORCPT ); Thu, 10 Nov 2005 14:51:16 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 491CCC048 for ; Thu, 10 Nov 2005 15:52:38 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 23EA11BC08B for ; Thu, 10 Nov 2005 15:52:42 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 494921A18A5 for ; Thu, 10 Nov 2005 15:52:42 +0100 (CET) Subject: smc91x support From: Matej Kupljen To: linux-mips@linux-mips.org Content-Type: text/plain Date: Thu, 10 Nov 2005 15:52:11 +0100 Message-Id: <1131634331.18165.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9464 X-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 On 21st september Peter Popov modified: arch/mips/au1000/common/platform.c With the log message: smc91x platform support; requires patch to smc91x.h which was sent upstream. Any news about this? What is the patch required for smc91x.h? I also added support for smc91x.h to enable it on the DBAU1200, but as I wrote in another mail, I get bad performance. I enabled the debug mode and I now I see that I get a lot of overruns, like: ... [4294761.172000] eth0: RX overrun (EPH_ST 0x0001) [4294761.190000] eth0: RX overrun (EPH_ST 0x0001) [4294761.198000] eth0: RX overrun (EPH_ST 0x0001) ... Is there any solution to this? Maybe to use DDMA? BR, Matej From anemo@mba.ocn.ne.jp Thu Nov 10 15:15:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 15:15:29 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:33508 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S3457893AbVKJPPL (ORCPT ); Thu, 10 Nov 2005 15:15:11 +0000 Received: from localhost (p5132-ipad207funabasi.chiba.ocn.ne.jp [222.145.87.132]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 5EAB8AC43; Fri, 11 Nov 2005 00:16:39 +0900 (JST) Date: Fri, 11 Nov 2005 00:15:43 +0900 (JST) Message-Id: <20051111.001543.93019156.anemo@mba.ocn.ne.jp> To: matej.kupljen@ultra.si Cc: linux-mips@linux-mips.org Subject: Re: smc91x support From: Atsushi Nemoto In-Reply-To: <1131634331.18165.30.camel@localhost.localdomain> References: <1131634331.18165.30.camel@localhost.localdomain> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9465 X-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, 10 Nov 2005 15:52:11 +0100, Matej Kupljen said: matej> What is the patch required for smc91x.h? I also want to know about the patch. matej> I also added support for smc91x.h to enable it on the DBAU1200, matej> but as I wrote in another mail, I get bad performance. I matej> enabled the debug mode and I now I see that I get a lot of matej> overruns, like: matej> ... matej> [4294761.172000] eth0: RX overrun (EPH_ST 0x0001) matej> [4294761.190000] eth0: RX overrun (EPH_ST 0x0001) matej> [4294761.198000] eth0: RX overrun (EPH_ST 0x0001) matej> ... matej> Is there any solution to this? I have similar problem on my several custom boards with SMC91C111. I see so many RX overrun, but I can not see why it happens. Forcing to 10Mbps/HalfDuplex reduced the overrun count (and works better than 100Mbps), but it is not preferable, of course ... --- Atsushi Nemoto From ppopov@embeddedalley.com Thu Nov 10 15:28:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 15:28:36 +0000 (GMT) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:50050 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3457893AbVKJP2R (ORCPT ); Thu, 10 Nov 2005 15:28:17 +0000 Received: (qmail 80469 invoked from network); 10 Nov 2005 15:29:41 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 10 Nov 2005 15:29:41 -0000 Subject: Re: smc91x support From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Matej Kupljen Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <1131634331.18165.30.camel@localhost.localdomain> References: <1131634331.18165.30.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-cxSBhw4V0vKhXoRAS6M9" Organization: Embedded Alley Solutions, Inc Date: Thu, 10 Nov 2005 07:29:45 -0800 Message-Id: <1131636585.4890.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9466 X-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 --=-cxSBhw4V0vKhXoRAS6M9 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-11-10 at 15:52 +0100, Matej Kupljen wrote: > Hi > > On 21st september Peter Popov modified: > arch/mips/au1000/common/platform.c > > With the log message: > smc91x platform support; requires patch to smc91x.h which was sent > upstream. > > Any news about this? > What is the patch required for smc91x.h? I have to check with Nicolas Pitre. Meanwhile I've attached the patch here. > I also added support for smc91x.h to enable it on the DBAU1200, > but as I wrote in another mail, I get bad performance. So do I. That part is just a low performance part plus the bus settings on the db1200 are set for the slowest part on the local bus. Depending on which peripherals you use on the local bus, you may be able to change the settings and get better performance from the Ethernet. Jordan may have more hints about this. Pete > I enabled the debug mode and I now I see that I get a lot of > overruns, like: > ... > [4294761.172000] eth0: RX overrun (EPH_ST 0x0001) > [4294761.190000] eth0: RX overrun (EPH_ST 0x0001) > [4294761.198000] eth0: RX overrun (EPH_ST 0x0001) > ... > > Is there any solution to this? > Maybe to use DDMA? > > BR, > Matej > > --=-cxSBhw4V0vKhXoRAS6M9 Content-Disposition: attachment; filename=smc91x_au1x.patch Content-Type: text/x-patch; name=smc91x_au1x.patch; charset=utf-8 Content-Transfer-Encoding: 7bit diff -Naur --exclude=CVS linux-2.6-orig/drivers/net/Kconfig linux-2.6-dev/drivers/net/Kconfig --- linux-2.6-orig/drivers/net/Kconfig 2005-09-15 08:45:33.000000000 -0700 +++ linux-2.6-dev/drivers/net/Kconfig 2005-09-21 11:40:13.000000000 -0700 @@ -800,7 +800,7 @@ tristate "SMC 91C9x/91C1xxx support" select CRC32 select MII - depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH) + depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || SOC_AU1X00) help This is a driver for SMC's 91x series of Ethernet chipsets, including the SMC91C94 and the SMC91C111. Say Y if you want it diff -Naur --exclude=CVS linux-2.6-orig/drivers/net/smc91x.h linux-2.6-dev/drivers/net/smc91x.h --- linux-2.6-orig/drivers/net/smc91x.h 2005-09-15 08:45:41.000000000 -0700 +++ linux-2.6-dev/drivers/net/smc91x.h 2005-09-21 11:42:49.000000000 -0700 @@ -289,6 +289,38 @@ #define RPC_LSA_DEFAULT RPC_LED_TX_RX #define RPC_LSB_DEFAULT RPC_LED_100_10 +#elif defined(CONFIG_SOC_AU1X00) + +#include + +/* We can only do 16-bit reads and writes in the static memory space. */ +#define SMC_CAN_USE_8BIT 0 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 0 +#define SMC_IO_SHIFT 0 +#define SMC_NOWAIT 1 + +#define SMC_inw(a, r) au_readw((unsigned long)((a) + (r))) +#define SMC_insw(a, r, p, l) \ + do { \ + unsigned long _a = (unsigned long)((a) + (r)); \ + int _l = (l); \ + u16 *_p = (u16 *)(p); \ + while (_l-- > 0) \ + *_p++ = au_readw(_a); \ + } while(0) +#define SMC_outw(v, a, r) au_writew(v, (unsigned long)((a) + (r))) +#define SMC_outsw(a, r, p, l) \ + do { \ + unsigned long _a = (unsigned long)((a) + (r)); \ + int _l = (l); \ + const u16 *_p = (const u16 *)(p); \ + while (_l-- > 0) \ + au_writew(*_p++ , _a); \ + } while(0) + +#define set_irq_type(irq, type) do {} while (0) + #else #define SMC_CAN_USE_8BIT 1 --=-cxSBhw4V0vKhXoRAS6M9-- From pantelis.antoniou@gmail.com Thu Nov 10 15:31:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 15:31:38 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.200]:37055 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S3457893AbVKJPbU (ORCPT ); Thu, 10 Nov 2005 15:31:20 +0000 Received: by xproxy.gmail.com with SMTP id s19so513933wxc for ; Thu, 10 Nov 2005 07:32:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=oDMCejdXqKENZg8cJ/aXqQy97Ath27pj6dqknBayszhvIzC7wefy8wcvj1PiWR8Uzb4ZzXregp551Tep2zg2abQZvNK92HBzIK7FBDkoO3e1hCSPC0PLOgsNvMDMPf3AzG4XBMeBMtbTl+FUNJx0+uIfCsqMfHd8AprlJKGsIEQ= Received: by 10.70.100.17 with SMTP id x17mr839009wxb; Thu, 10 Nov 2005 07:32:48 -0800 (PST) Received: from pantathon.404.gr ( [195.97.100.53]) by mx.gmail.com with ESMTP id h39sm555234wxd.2005.11.10.07.32.22; Thu, 10 Nov 2005 07:32:48 -0800 (PST) From: Pantelis Antoniou Reply-To: pantelis.antoniou@gmail.com To: Atsushi Nemoto Subject: Re: smc91x support Date: Thu, 10 Nov 2005 17:37:08 +0200 User-Agent: KMail/1.8 Cc: matej.kupljen@ultra.si, linux-mips@linux-mips.org References: <1131634331.18165.30.camel@localhost.localdomain> <20051111.001543.93019156.anemo@mba.ocn.ne.jp> In-Reply-To: <20051111.001543.93019156.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101737.09316.pantelis.antoniou@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pantelis.antoniou@gmail.com Precedence: bulk X-list: linux-mips On Thursday 10 November 2005 17:15, Atsushi Nemoto wrote: > >>>>> On Thu, 10 Nov 2005 15:52:11 +0100, Matej Kupljen said: > > matej> What is the patch required for smc91x.h? > > I also want to know about the patch. > > matej> I also added support for smc91x.h to enable it on the DBAU1200, > matej> but as I wrote in another mail, I get bad performance. I > matej> enabled the debug mode and I now I see that I get a lot of > matej> overruns, like: > matej> ... > matej> [4294761.172000] eth0: RX overrun (EPH_ST 0x0001) > matej> [4294761.190000] eth0: RX overrun (EPH_ST 0x0001) > matej> [4294761.198000] eth0: RX overrun (EPH_ST 0x0001) > matej> ... > > matej> Is there any solution to this? > > I have similar problem on my several custom boards with SMC91C111. I > see so many RX overrun, but I can not see why it happens. Forcing to > 10Mbps/HalfDuplex reduced the overrun count (and works better than > 100Mbps), but it is not preferable, of course ... > > --- I'm afraid there's not much that you can do... The old driver just didn't report the overruns. The generic one does, that's why you see the overrun error. And yes performance is bad with this chip. I'm not sure if DMA would help much, since the overrun occurs because the chip does not have enough internal buffers. I don't think that we can service the interrupts fast enough to prevent the overruns... IMHO the only solution is to use a decent chip... > Atsushi Nemoto > > Regards Pantelis From matej.kupljen@ultra.si Thu Nov 10 17:43:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 17:43:26 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:59267 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S3458461AbVKJRnF (ORCPT ); Thu, 10 Nov 2005 17:43:05 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id BF5C3C06E; Thu, 10 Nov 2005 18:44:25 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 6E3C91BC07F; Thu, 10 Nov 2005 18:44:30 +0100 (CET) Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52]) by smtp.triera.net (Postfix) with ESMTP id 816DB1A18BD; Thu, 10 Nov 2005 18:44:30 +0100 (CET) Subject: Re: smc91x support From: Matej Kupljen To: pantelis.antoniou@gmail.com Cc: Atsushi Nemoto , linux-mips@linux-mips.org In-Reply-To: <200511101737.09316.pantelis.antoniou@gmail.com> References: <1131634331.18165.30.camel@localhost.localdomain> <20051111.001543.93019156.anemo@mba.ocn.ne.jp> <200511101737.09316.pantelis.antoniou@gmail.com> Content-Type: text/plain Organization: Ultra d.o.o. Date: Thu, 10 Nov 2005 18:44:30 +0100 Message-Id: <1131644670.1478.4.camel@orionlinux.starfleet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9468 X-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 > > matej> Is there any solution to this? > > > > I have similar problem on my several custom boards with SMC91C111. I > > see so many RX overrun, but I can not see why it happens. Forcing to > > 10Mbps/HalfDuplex reduced the overrun count (and works better than > > 100Mbps), but it is not preferable, of course ... How did you achieve this? By software or by using 10 Mbps switch? > And yes performance is bad with this chip. Probably I'll try and switch it to 10 Mbps, because NFS is terrible because it gets a lot of timeouts because of dropped packets. > I'm not sure if DMA would > help much, since the overrun occurs because the chip does not have > enough internal buffers. I don't think that we can service the interrupts > fast enough to prevent the overruns... I found this mail from Nicolas on ARM mailing list: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-October/031736.html Maybe we could try DMA and see what happens. Any hints how to try this, because I haven't worked with DDMA before? BR, Matej From matej.kupljen@ultra.si Thu Nov 10 17:51:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 17:51:35 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:61572 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S3458470AbVKJRvS (ORCPT ); Thu, 10 Nov 2005 17:51:18 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 51717C06E for ; Thu, 10 Nov 2005 18:52:40 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id 1654A1BC089 for ; Thu, 10 Nov 2005 18:52:45 +0100 (CET) Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52]) by smtp.triera.net (Postfix) with ESMTP id 9B3B41A18A5 for ; Thu, 10 Nov 2005 18:52:45 +0100 (CET) Subject: Re: smc91x support From: Matej Kupljen To: "'linux-mips@linux-mips.org'" In-Reply-To: <1131636585.4890.14.camel@localhost.localdomain> References: <1131634331.18165.30.camel@localhost.localdomain> <1131636585.4890.14.camel@localhost.localdomain> Content-Type: text/plain Organization: Ultra d.o.o. Date: Thu, 10 Nov 2005 18:52:47 +0100 Message-Id: <1131645167.1478.13.camel@orionlinux.starfleet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9469 X-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 > Meanwhile I've attached the patch here. Thank you. I'll check it with mine and let you know, what I did. Just one think: - depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH) + depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || SOC_AU1X00) Wouldn't it be better to use SOC_AU1200 instead of SOC_AU1X00, because only AU1200 does not have integrated Ethernet controller? BR, Matej From ppopov@embeddedalley.com Thu Nov 10 17:55:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Nov 2005 17:55:44 +0000 (GMT) Received: from web408.biz.mail.mud.yahoo.com ([68.142.201.39]:40598 "HELO web408.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3458471AbVKJRzZ (ORCPT ); Thu, 10 Nov 2005 17:55:25 +0000 Received: (qmail 44685 invoked by uid 60001); 10 Nov 2005 17:56:50 -0000 Message-ID: <20051110175650.44683.qmail@web408.biz.mail.mud.yahoo.com> Received: from [64.163.129.139] by web408.biz.mail.mud.yahoo.com via HTTP; Thu, 10 Nov 2005 09:56:50 PST Date: Thu, 10 Nov 2005 09:56:50 -0800 (PST) From: Peter Popov Subject: Re: smc91x support To: Matej Kupljen , "'linux-mips@linux-mips.org'" In-Reply-To: <1131645167.1478.13.camel@orionlinux.starfleet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9470 X-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 > Wouldn't it be better to use SOC_AU1200 instead of > SOC_AU1X00, because > only AU1200 does not have integrated Ethernet > controller? Perhaps. But the Au1x could use it ... depending on the HW design. Right now only the Db1200 has this chip. Pete From nemoto@toshiba-tops.co.jp Fri Nov 11 01:33:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Nov 2005 01:34:05 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:12322 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S3458499AbVKKBdq (ORCPT ); Fri, 11 Nov 2005 01:33:46 +0000 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; 11 Nov 2005 01:36:26 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 2B17420029; Fri, 11 Nov 2005 10:36:22 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 1F79520025; Fri, 11 Nov 2005 10:36:22 +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 jAB1aJhO017697; Fri, 11 Nov 2005 10:36:20 +0900 (JST) (envelope-from nemoto@toshiba-tops.co.jp) Date: Fri, 11 Nov 2005 10:36:19 +0900 (JST) Message-Id: <20051111.103619.25910589.nemoto@toshiba-tops.co.jp> To: matej.kupljen@ultra.si Cc: pantelis.antoniou@gmail.com, anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org Subject: Re: smc91x support From: Atsushi Nemoto In-Reply-To: <1131644670.1478.4.camel@orionlinux.starfleet.com> References: <20051111.001543.93019156.anemo@mba.ocn.ne.jp> <200511101737.09316.pantelis.antoniou@gmail.com> <1131644670.1478.4.camel@orionlinux.starfleet.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 Organization: TOSHIBA Personal Computer System Corporation 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nemoto@toshiba-tops.co.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 10 Nov 2005 18:44:30 +0100, Matej Kupljen said: matej> How did you achieve this? By software or by using 10 Mbps matej> switch? I did by just change default settings like this: /* Set default parameters */ lp->msg_enable = NETIF_MSG_LINK; lp->ctl_rfduplx = 0; lp->ctl_rspeed = 10; #if 0 /* too many rx overruns on 100M... why? (less overruns on 10M) */ if (lp->version >= (CHIP_91100 << 4)) { lp->ctl_rfduplx = 1; lp->ctl_rspeed = 100; } #endif matej> I found this mail from Nicolas on ARM mailing list: matej> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-October/031736.html Hmm... Thanks. --- Atsushi Nemoto From adobriyan@gmail.com Sat Nov 12 19:50:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 19:50:22 +0000 (GMT) Received: from xproxy.gmail.com ([66.249.82.204]:38859 "EHLO xproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133877AbVKLTuC (ORCPT ); Sat, 12 Nov 2005 19:50:02 +0000 Received: by xproxy.gmail.com with SMTP id h30so1028952wxd for ; Sat, 12 Nov 2005 11:51:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=iguOMrw9MFXLQrwwqbo6njnS4MN2EGLDZIbRRogNlRnA0VOV+vNxU/EEogFX2mx+ql3DnC1zj9n/BFXHWu6uF+D2nbgkNjpd/T9C0m3BxTL9SebZUFu3paxXcO7CNckSxiSkucwA+klbo7pAcAQfuFnYWeRY/Www3N89OJ2fr9w= Received: by 10.65.155.17 with SMTP id h17mr3943669qbo; Sat, 12 Nov 2005 11:51:43 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id e14sm729083qba.2005.11.12.11.51.40; Sat, 12 Nov 2005 11:51:43 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Sat, 12 Nov 2005 23:05:25 +0300 (MSK) Date: Sat, 12 Nov 2005 23:05:21 +0300 From: Alexey Dobriyan To: Ralf Baechle , Andrew Morton Cc: Domen Puncer , linux-mips@linux-mips.org Subject: [PATCH] Remove include/asm-mips/gfx.h Message-ID: <20051112200521.GD19876@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Domen Puncer Remove nowhere referenced file ("grep 'gfx\.' -r ." didn't find anything). Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/include/asm-mips/gfx.h =================================================================== --- linux-kj.orig/include/asm-mips/gfx.h 2005-11-12 15:37:57.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,55 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * This is the user-visible SGI GFX interface. - * - * This must be used verbatim into the GNU libc. It does not include - * any kernel-only bits on it. - * - * miguel@nuclecu.unam.mx - */ -#ifndef _ASM_GFX_H -#define _ASM_GFX_H - -/* The iocls, yes, they do not make sense, but such is life */ -#define GFX_BASE 100 -#define GFX_GETNUM_BOARDS (GFX_BASE + 1) -#define GFX_GETBOARD_INFO (GFX_BASE + 2) -#define GFX_ATTACH_BOARD (GFX_BASE + 3) -#define GFX_DETACH_BOARD (GFX_BASE + 4) -#define GFX_IS_MANAGED (GFX_BASE + 5) - -#define GFX_MAPALL (GFX_BASE + 10) -#define GFX_LABEL (GFX_BASE + 11) - -#define GFX_INFO_NAME_SIZE 16 -#define GFX_INFO_LABEL_SIZE 16 - -struct gfx_info { - char name [GFX_INFO_NAME_SIZE]; /* board name */ - char label [GFX_INFO_LABEL_SIZE]; /* label name */ - unsigned short int xpmax, ypmax; /* screen resolution */ - unsigned int lenght; /* size of a complete gfx_info for this board */ -}; - -struct gfx_getboardinfo_args { - unsigned int board; /* board number. starting from zero */ - void *buf; /* pointer to gfx_info */ - unsigned int len; /* buffer size of buf */ -}; - -struct gfx_attach_board_args { - unsigned int board; /* board number, starting from zero */ - void *vaddr; /* address where the board registers should be mapped */ -}; - -#ifdef __KERNEL__ -/* umap.c */ -extern void remove_mapping (struct vm_area_struct *vma, struct task_struct *, unsigned long, unsigned long); -extern void *vmalloc_uncached (unsigned long size); -extern int vmap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long size, unsigned long vaddr); -#endif - -#endif /* _ASM_GFX_H */ From adobriyan@gmail.com Sat Nov 12 20:21:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 20:22:09 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.203]:46457 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133879AbVKLUVu (ORCPT ); Sat, 12 Nov 2005 20:21:50 +0000 Received: by wproxy.gmail.com with SMTP id i5so483974wra for ; Sat, 12 Nov 2005 12:23:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=SSEquN8kYvWmOpu/4Q42CPHuVlM9shqEgLyjgaFVFivFwA8HrU7z/NPE2GUCaZy8FBmitO9nW4NJcPzISmpp2v2YtjfracRIAF8i+nGLdmyBXyrgEqOckx9ts8NAlOTmdEOtFKhZiZLcWWE2aQFujL3P30jZyZl/HXgNUgELrwU= Received: by 10.65.233.6 with SMTP id k6mr3899417qbr; Sat, 12 Nov 2005 12:23:33 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id e15sm762466qba.2005.11.12.12.23.30; Sat, 12 Nov 2005 12:23:32 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Sat, 12 Nov 2005 23:37:14 +0300 (MSK) Date: Sat, 12 Nov 2005 23:37:11 +0300 From: Alexey Dobriyan To: Ralf Baechle , Andrew Morton Cc: Domen Puncer , linux-mips@linux-mips.org Subject: [PATCH] Remove include/asm-mips/mipsprom.h Message-ID: <20051112203711.GE19876@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Domen Puncer Remove nowhere referenced file ("grep mipsrom -r ." didn't find anything). Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/include/asm-mips/mipsprom.h =================================================================== --- linux-kj.orig/include/asm-mips/mipsprom.h 2005-11-12 15:38:00.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,74 +0,0 @@ -#ifndef __ASM_MIPS_PROM_H -#define __ASM_MIPS_PROM_H - -#define PROM_RESET 0 -#define PROM_EXEC 1 -#define PROM_RESTART 2 -#define PROM_REINIT 3 -#define PROM_REBOOT 4 -#define PROM_AUTOBOOT 5 -#define PROM_OPEN 6 -#define PROM_READ 7 -#define PROM_WRITE 8 -#define PROM_IOCTL 9 -#define PROM_CLOSE 10 -#define PROM_GETCHAR 11 -#define PROM_PUTCHAR 12 -#define PROM_SHOWCHAR 13 /* XXX */ -#define PROM_GETS 14 /* XXX */ -#define PROM_PUTS 15 /* XXX */ -#define PROM_PRINTF 16 /* XXX */ - -/* What are these for? */ -#define PROM_INITPROTO 17 /* XXX */ -#define PROM_PROTOENABLE 18 /* XXX */ -#define PROM_PROTODISABLE 19 /* XXX */ -#define PROM_GETPKT 20 /* XXX */ -#define PROM_PUTPKT 21 /* XXX */ - -/* More PROM shit. Probably has to do with VME RMW cycles??? */ -#define PROM_ORW_RMW 22 /* XXX */ -#define PROM_ORH_RMW 23 /* XXX */ -#define PROM_ORB_RMW 24 /* XXX */ -#define PROM_ANDW_RMW 25 /* XXX */ -#define PROM_ANDH_RMW 26 /* XXX */ -#define PROM_ANDB_RMW 27 /* XXX */ - -/* Cache handling stuff */ -#define PROM_FLUSHCACHE 28 /* XXX */ -#define PROM_CLEARCACHE 29 /* XXX */ - -/* Libc alike stuff */ -#define PROM_SETJMP 30 /* XXX */ -#define PROM_LONGJMP 31 /* XXX */ -#define PROM_BEVUTLB 32 /* XXX */ -#define PROM_GETENV 33 /* XXX */ -#define PROM_SETENV 34 /* XXX */ -#define PROM_ATOB 35 /* XXX */ -#define PROM_STRCMP 36 /* XXX */ -#define PROM_STRLEN 37 /* XXX */ -#define PROM_STRCPY 38 /* XXX */ -#define PROM_STRCAT 39 /* XXX */ - -/* Misc stuff */ -#define PROM_PARSER 40 /* XXX */ -#define PROM_RANGE 41 /* XXX */ -#define PROM_ARGVIZE 42 /* XXX */ -#define PROM_HELP 43 /* XXX */ - -/* Entry points for some PROM commands */ -#define PROM_DUMPCMD 44 /* XXX */ -#define PROM_SETENVCMD 45 /* XXX */ -#define PROM_UNSETENVCMD 46 /* XXX */ -#define PROM_PRINTENVCMD 47 /* XXX */ -#define PROM_BEVEXCEPT 48 /* XXX */ -#define PROM_ENABLECMD 49 /* XXX */ -#define PROM_DISABLECMD 50 /* XXX */ - -#define PROM_CLEARNOFAULT 51 /* XXX */ -#define PROM_NOTIMPLEMENT 52 /* XXX */ - -#define PROM_NV_GET 53 /* XXX */ -#define PROM_NV_SET 54 /* XXX */ - -#endif /* __ASM_MIPS_PROM_H */ From adobriyan@gmail.com Sat Nov 12 20:23:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 20:24:02 +0000 (GMT) Received: from zproxy.gmail.com ([64.233.162.193]:38229 "EHLO zproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133879AbVKLUXa (ORCPT ); Sat, 12 Nov 2005 20:23:30 +0000 Received: by zproxy.gmail.com with SMTP id 4so440903nzn for ; Sat, 12 Nov 2005 12:25:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=tOkvlv2jmxBgVApIPFVfX64wtvxRZlOHbU/wG1/maKymzjSxBh4Uc6JuRbI2nZRXyg1VeN4GQ2GLe01Vke28gNJAydnUnac7S6OTSEr9wwfCc4+XKsR1/vMh75kdDrhPxCGVkm+yNNEAMFuzMyKD6lbmcSBWFftJf87dskSBecE= Received: by 10.64.27.16 with SMTP id a16mr2882600qba; Sat, 12 Nov 2005 12:25:12 -0800 (PST) Received: from gmail.com ( [217.10.38.130]) by mx.gmail.com with ESMTP id e14sm749916qba.2005.11.12.12.25.08; Sat, 12 Nov 2005 12:25:11 -0800 (PST) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Sat, 12 Nov 2005 23:38:52 +0300 (MSK) Date: Sat, 12 Nov 2005 23:38:48 +0300 From: Alexey Dobriyan To: Ralf Baechle , Andrew Morton Cc: Domen Puncer , linux-mips@linux-mips.org Subject: [PATCH] Remove include/asm-mips/riscos-syscall.h Message-ID: <20051112203848.GF19876@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: linux-mips From: Domen Puncer Remove nowhere referenced file ("grep riscos -r ." didn't find anything). Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Index: linux-kj/include/asm-mips/riscos-syscall.h =================================================================== --- linux-kj.orig/include/asm-mips/riscos-syscall.h 2005-11-12 15:37:58.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,979 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1995, 96, 97, 98, 99, 2000 by Ralf Baechle - */ -#ifndef _ASM_RISCOS_SYSCALL_H -#define _ASM_RISCOS_SYSCALL_H - -/* - * The syscalls 0 - 3999 are reserved for a down to the root syscall - * compatibility with RISC/os and IRIX. We'll see how to deal with the - * various "real" BSD variants like Ultrix, NetBSD ... - */ - -/* - * SVR4 syscalls are in the range from 1 to 999 - */ -#define __NR_SVR4 0 -#define __NR_SVR4_syscall (__NR_SVR4 + 0) -#define __NR_SVR4_exit (__NR_SVR4 + 1) -#define __NR_SVR4_fork (__NR_SVR4 + 2) -#define __NR_SVR4_read (__NR_SVR4 + 3) -#define __NR_SVR4_write (__NR_SVR4 + 4) -#define __NR_SVR4_open (__NR_SVR4 + 5) -#define __NR_SVR4_close (__NR_SVR4 + 6) -#define __NR_SVR4_wait (__NR_SVR4 + 7) -#define __NR_SVR4_creat (__NR_SVR4 + 8) -#define __NR_SVR4_link (__NR_SVR4 + 9) -#define __NR_SVR4_unlink (__NR_SVR4 + 10) -#define __NR_SVR4_exec (__NR_SVR4 + 11) -#define __NR_SVR4_chdir (__NR_SVR4 + 12) -#define __NR_SVR4_gtime (__NR_SVR4 + 13) -#define __NR_SVR4_mknod (__NR_SVR4 + 14) -#define __NR_SVR4_chmod (__NR_SVR4 + 15) -#define __NR_SVR4_chown (__NR_SVR4 + 16) -#define __NR_SVR4_sbreak (__NR_SVR4 + 17) -#define __NR_SVR4_stat (__NR_SVR4 + 18) -#define __NR_SVR4_lseek (__NR_SVR4 + 19) -#define __NR_SVR4_getpid (__NR_SVR4 + 20) -#define __NR_SVR4_mount (__NR_SVR4 + 21) -#define __NR_SVR4_umount (__NR_SVR4 + 22) -#define __NR_SVR4_setuid (__NR_SVR4 + 23) -#define __NR_SVR4_getuid (__NR_SVR4 + 24) -#define __NR_SVR4_stime (__NR_SVR4 + 25) -#define __NR_SVR4_ptrace (__NR_SVR4 + 26) -#define __NR_SVR4_alarm (__NR_SVR4 + 27) -#define __NR_SVR4_fstat (__NR_SVR4 + 28) -#define __NR_SVR4_pause (__NR_SVR4 + 29) -#define __NR_SVR4_utime (__NR_SVR4 + 30) -#define __NR_SVR4_stty (__NR_SVR4 + 31) -#define __NR_SVR4_gtty (__NR_SVR4 + 32) -#define __NR_SVR4_access (__NR_SVR4 + 33) -#define __NR_SVR4_nice (__NR_SVR4 + 34) -#define __NR_SVR4_statfs (__NR_SVR4 + 35) -#define __NR_SVR4_sync (__NR_SVR4 + 36) -#define __NR_SVR4_kill (__NR_SVR4 + 37) -#define __NR_SVR4_fstatfs (__NR_SVR4 + 38) -#define __NR_SVR4_setpgrp (__NR_SVR4 + 39) -#define __NR_SVR4_cxenix (__NR_SVR4 + 40) -#define __NR_SVR4_dup (__NR_SVR4 + 41) -#define __NR_SVR4_pipe (__NR_SVR4 + 42) -#define __NR_SVR4_times (__NR_SVR4 + 43) -#define __NR_SVR4_profil (__NR_SVR4 + 44) -#define __NR_SVR4_plock (__NR_SVR4 + 45) -#define __NR_SVR4_setgid (__NR_SVR4 + 46) -#define __NR_SVR4_getgid (__NR_SVR4 + 47) -#define __NR_SVR4_sig (__NR_SVR4 + 48) -#define __NR_SVR4_msgsys (__NR_SVR4 + 49) -#define __NR_SVR4_sysmips (__NR_SVR4 + 50) -#define __NR_SVR4_sysacct (__NR_SVR4 + 51) -#define __NR_SVR4_shmsys (__NR_SVR4 + 52) -#define __NR_SVR4_semsys (__NR_SVR4 + 53) -#define __NR_SVR4_ioctl (__NR_SVR4 + 54) -#define __NR_SVR4_uadmin (__NR_SVR4 + 55) -#define __NR_SVR4_exch (__NR_SVR4 + 56) -#define __NR_SVR4_utssys (__NR_SVR4 + 57) -#define __NR_SVR4_fsync (__NR_SVR4 + 58) -#define __NR_SVR4_exece (__NR_SVR4 + 59) -#define __NR_SVR4_umask (__NR_SVR4 + 60) -#define __NR_SVR4_chroot (__NR_SVR4 + 61) -#define __NR_SVR4_fcntl (__NR_SVR4 + 62) -#define __NR_SVR4_ulimit (__NR_SVR4 + 63) -#define __NR_SVR4_reserved1 (__NR_SVR4 + 64) -#define __NR_SVR4_reserved2 (__NR_SVR4 + 65) -#define __NR_SVR4_reserved3 (__NR_SVR4 + 66) -#define __NR_SVR4_reserved4 (__NR_SVR4 + 67) -#define __NR_SVR4_reserved5 (__NR_SVR4 + 68) -#define __NR_SVR4_reserved6 (__NR_SVR4 + 69) -#define __NR_SVR4_advfs (__NR_SVR4 + 70) -#define __NR_SVR4_unadvfs (__NR_SVR4 + 71) -#define __NR_SVR4_unused1 (__NR_SVR4 + 72) -#define __NR_SVR4_unused2 (__NR_SVR4 + 73) -#define __NR_SVR4_rfstart (__NR_SVR4 + 74) -#define __NR_SVR4_unused3 (__NR_SVR4 + 75) -#define __NR_SVR4_rdebug (__NR_SVR4 + 76) -#define __NR_SVR4_rfstop (__NR_SVR4 + 77) -#define __NR_SVR4_rfsys (__NR_SVR4 + 78) -#define __NR_SVR4_rmdir (__NR_SVR4 + 79) -#define __NR_SVR4_mkdir (__NR_SVR4 + 80) -#define __NR_SVR4_getdents (__NR_SVR4 + 81) -#define __NR_SVR4_libattach (__NR_SVR4 + 82) -#define __NR_SVR4_libdetach (__NR_SVR4 + 83) -#define __NR_SVR4_sysfs (__NR_SVR4 + 84) -#define __NR_SVR4_getmsg (__NR_SVR4 + 85) -#define __NR_SVR4_putmsg (__NR_SVR4 + 86) -#define __NR_SVR4_poll (__NR_SVR4 + 87) -#define __NR_SVR4_lstat (__NR_SVR4 + 88) -#define __NR_SVR4_symlink (__NR_SVR4 + 89) -#define __NR_SVR4_readlink (__NR_SVR4 + 90) -#define __NR_SVR4_setgroups (__NR_SVR4 + 91) -#define __NR_SVR4_getgroups (__NR_SVR4 + 92) -#define __NR_SVR4_fchmod (__NR_SVR4 + 93) -#define __NR_SVR4_fchown (__NR_SVR4 + 94) -#define __NR_SVR4_sigprocmask (__NR_SVR4 + 95) -#define __NR_SVR4_sigsuspend (__NR_SVR4 + 96) -#define __NR_SVR4_sigaltstack (__NR_SVR4 + 97) -#define __NR_SVR4_sigaction (__NR_SVR4 + 98) -#define __NR_SVR4_sigpending (__NR_SVR4 + 99) -#define __NR_SVR4_setcontext (__NR_SVR4 + 100) -#define __NR_SVR4_evsys (__NR_SVR4 + 101) -#define __NR_SVR4_evtrapret (__NR_SVR4 + 102) -#define __NR_SVR4_statvfs (__NR_SVR4 + 103) -#define __NR_SVR4_fstatvfs (__NR_SVR4 + 104) -#define __NR_SVR4_reserved7 (__NR_SVR4 + 105) -#define __NR_SVR4_nfssys (__NR_SVR4 + 106) -#define __NR_SVR4_waitid (__NR_SVR4 + 107) -#define __NR_SVR4_sigsendset (__NR_SVR4 + 108) -#define __NR_SVR4_hrtsys (__NR_SVR4 + 109) -#define __NR_SVR4_acancel (__NR_SVR4 + 110) -#define __NR_SVR4_async (__NR_SVR4 + 111) -#define __NR_SVR4_priocntlset (__NR_SVR4 + 112) -#define __NR_SVR4_pathconf (__NR_SVR4 + 113) -#define __NR_SVR4_mincore (__NR_SVR4 + 114) -#define __NR_SVR4_mmap (__NR_SVR4 + 115) -#define __NR_SVR4_mprotect (__NR_SVR4 + 116) -#define __NR_SVR4_munmap (__NR_SVR4 + 117) -#define __NR_SVR4_fpathconf (__NR_SVR4 + 118) -#define __NR_SVR4_vfork (__NR_SVR4 + 119) -#define __NR_SVR4_fchdir (__NR_SVR4 + 120) -#define __NR_SVR4_readv (__NR_SVR4 + 121) -#define __NR_SVR4_writev (__NR_SVR4 + 122) -#define __NR_SVR4_xstat (__NR_SVR4 + 123) -#define __NR_SVR4_lxstat (__NR_SVR4 + 124) -#define __NR_SVR4_fxstat (__NR_SVR4 + 125) -#define __NR_SVR4_xmknod (__NR_SVR4 + 126) -#define __NR_SVR4_clocal (__NR_SVR4 + 127) -#define __NR_SVR4_setrlimit (__NR_SVR4 + 128) -#define __NR_SVR4_getrlimit (__NR_SVR4 + 129) -#define __NR_SVR4_lchown (__NR_SVR4 + 130) -#define __NR_SVR4_memcntl (__NR_SVR4 + 131) -#define __NR_SVR4_getpmsg (__NR_SVR4 + 132) -#define __NR_SVR4_putpmsg (__NR_SVR4 + 133) -#define __NR_SVR4_rename (__NR_SVR4 + 134) -#define __NR_SVR4_nuname (__NR_SVR4 + 135) -#define __NR_SVR4_setegid (__NR_SVR4 + 136) -#define __NR_SVR4_sysconf (__NR_SVR4 + 137) -#define __NR_SVR4_adjtime (__NR_SVR4 + 138) -#define __NR_SVR4_sysinfo (__NR_SVR4 + 139) -#define __NR_SVR4_reserved8 (__NR_SVR4 + 140) -#define __NR_SVR4_seteuid (__NR_SVR4 + 141) -#define __NR_SVR4_PYRAMID_statis (__NR_SVR4 + 142) -#define __NR_SVR4_PYRAMID_tuning (__NR_SVR4 + 143) -#define __NR_SVR4_PYRAMID_forcerr (__NR_SVR4 + 144) -#define __NR_SVR4_PYRAMID_mpcntl (__NR_SVR4 + 145) -#define __NR_SVR4_reserved9 (__NR_SVR4 + 146) -#define __NR_SVR4_reserved10 (__NR_SVR4 + 147) -#define __NR_SVR4_reserved11 (__NR_SVR4 + 148) -#define __NR_SVR4_reserved12 (__NR_SVR4 + 149) -#define __NR_SVR4_reserved13 (__NR_SVR4 + 150) -#define __NR_SVR4_reserved14 (__NR_SVR4 + 151) -#define __NR_SVR4_reserved15 (__NR_SVR4 + 152) -#define __NR_SVR4_reserved16 (__NR_SVR4 + 153) -#define __NR_SVR4_reserved17 (__NR_SVR4 + 154) -#define __NR_SVR4_reserved18 (__NR_SVR4 + 155) -#define __NR_SVR4_reserved19 (__NR_SVR4 + 156) -#define __NR_SVR4_reserved20 (__NR_SVR4 + 157) -#define __NR_SVR4_reserved21 (__NR_SVR4 + 158) -#define __NR_SVR4_reserved22 (__NR_SVR4 + 159) -#define __NR_SVR4_reserved23 (__NR_SVR4 + 160) -#define __NR_SVR4_reserved24 (__NR_SVR4 + 161) -#define __NR_SVR4_reserved25 (__NR_SVR4 + 162) -#define __NR_SVR4_reserved26 (__NR_SVR4 + 163) -#define __NR_SVR4_reserved27 (__NR_SVR4 + 164) -#define __NR_SVR4_reserved28 (__NR_SVR4 + 165) -#define __NR_SVR4_reserved29 (__NR_SVR4 + 166) -#define __NR_SVR4_reserved30 (__NR_SVR4 + 167) -#define __NR_SVR4_reserved31 (__NR_SVR4 + 168) -#define __NR_SVR4_reserved32 (__NR_SVR4 + 169) -#define __NR_SVR4_reserved33 (__NR_SVR4 + 170) -#define __NR_SVR4_reserved34 (__NR_SVR4 + 171) -#define __NR_SVR4_reserved35 (__NR_SVR4 + 172) -#define __NR_SVR4_reserved36 (__NR_SVR4 + 173) -#define __NR_SVR4_reserved37 (__NR_SVR4 + 174) -#define __NR_SVR4_reserved38 (__NR_SVR4 + 175) -#define __NR_SVR4_reserved39 (__NR_SVR4 + 176) -#define __NR_SVR4_reserved40 (__NR_SVR4 + 177) -#define __NR_SVR4_reserved41 (__NR_SVR4 + 178) -#define __NR_SVR4_reserved42 (__NR_SVR4 + 179) -#define __NR_SVR4_reserved43 (__NR_SVR4 + 180) -#define __NR_SVR4_reserved44 (__NR_SVR4 + 181) -#define __NR_SVR4_reserved45 (__NR_SVR4 + 182) -#define __NR_SVR4_reserved46 (__NR_SVR4 + 183) -#define __NR_SVR4_reserved47 (__NR_SVR4 + 184) -#define __NR_SVR4_reserved48 (__NR_SVR4 + 185) -#define __NR_SVR4_reserved49 (__NR_SVR4 + 186) -#define __NR_SVR4_reserved50 (__NR_SVR4 + 187) -#define __NR_SVR4_reserved51 (__NR_SVR4 + 188) -#define __NR_SVR4_reserved52 (__NR_SVR4 + 189) -#define __NR_SVR4_reserved53 (__NR_SVR4 + 190) -#define __NR_SVR4_reserved54 (__NR_SVR4 + 191) -#define __NR_SVR4_reserved55 (__NR_SVR4 + 192) -#define __NR_SVR4_reserved56 (__NR_SVR4 + 193) -#define __NR_SVR4_reserved57 (__NR_SVR4 + 194) -#define __NR_SVR4_reserved58 (__NR_SVR4 + 195) -#define __NR_SVR4_reserved59 (__NR_SVR4 + 196) -#define __NR_SVR4_reserved60 (__NR_SVR4 + 197) -#define __NR_SVR4_reserved61 (__NR_SVR4 + 198) -#define __NR_SVR4_reserved62 (__NR_SVR4 + 199) -#define __NR_SVR4_reserved63 (__NR_SVR4 + 200) -#define __NR_SVR4_aread (__NR_SVR4 + 201) -#define __NR_SVR4_awrite (__NR_SVR4 + 202) -#define __NR_SVR4_listio (__NR_SVR4 + 203) -#define __NR_SVR4_mips_acancel (__NR_SVR4 + 204) -#define __NR_SVR4_astatus (__NR_SVR4 + 205) -#define __NR_SVR4_await (__NR_SVR4 + 206) -#define __NR_SVR4_areadv (__NR_SVR4 + 207) -#define __NR_SVR4_awritev (__NR_SVR4 + 208) -#define __NR_SVR4_MIPS_reserved1 (__NR_SVR4 + 209) -#define __NR_SVR4_MIPS_reserved2 (__NR_SVR4 + 210) -#define __NR_SVR4_MIPS_reserved3 (__NR_SVR4 + 211) -#define __NR_SVR4_MIPS_reserved4 (__NR_SVR4 + 212) -#define __NR_SVR4_MIPS_reserved5 (__NR_SVR4 + 213) -#define __NR_SVR4_MIPS_reserved6 (__NR_SVR4 + 214) -#define __NR_SVR4_MIPS_reserved7 (__NR_SVR4 + 215) -#define __NR_SVR4_MIPS_reserved8 (__NR_SVR4 + 216) -#define __NR_SVR4_MIPS_reserved9 (__NR_SVR4 + 217) -#define __NR_SVR4_MIPS_reserved10 (__NR_SVR4 + 218) -#define __NR_SVR4_MIPS_reserved11 (__NR_SVR4 + 219) -#define __NR_SVR4_MIPS_reserved12 (__NR_SVR4 + 220) -#define __NR_SVR4_CDC_reserved1 (__NR_SVR4 + 221) -#define __NR_SVR4_CDC_reserved2 (__NR_SVR4 + 222) -#define __NR_SVR4_CDC_reserved3 (__NR_SVR4 + 223) -#define __NR_SVR4_CDC_reserved4 (__NR_SVR4 + 224) -#define __NR_SVR4_CDC_reserved5 (__NR_SVR4 + 225) -#define __NR_SVR4_CDC_reserved6 (__NR_SVR4 + 226) -#define __NR_SVR4_CDC_reserved7 (__NR_SVR4 + 227) -#define __NR_SVR4_CDC_reserved8 (__NR_SVR4 + 228) -#define __NR_SVR4_CDC_reserved9 (__NR_SVR4 + 229) -#define __NR_SVR4_CDC_reserved10 (__NR_SVR4 + 230) -#define __NR_SVR4_CDC_reserved11 (__NR_SVR4 + 231) -#define __NR_SVR4_CDC_reserved12 (__NR_SVR4 + 232) -#define __NR_SVR4_CDC_reserved13 (__NR_SVR4 + 233) -#define __NR_SVR4_CDC_reserved14 (__NR_SVR4 + 234) -#define __NR_SVR4_CDC_reserved15 (__NR_SVR4 + 235) -#define __NR_SVR4_CDC_reserved16 (__NR_SVR4 + 236) -#define __NR_SVR4_CDC_reserved17 (__NR_SVR4 + 237) -#define __NR_SVR4_CDC_reserved18 (__NR_SVR4 + 238) -#define __NR_SVR4_CDC_reserved19 (__NR_SVR4 + 239) -#define __NR_SVR4_CDC_reserved20 (__NR_SVR4 + 240) - -/* - * SYS V syscalls are in the range from 1000 to 1999 - */ -#define __NR_SYSV 1000 -#define __NR_SYSV_syscall (__NR_SYSV + 0) -#define __NR_SYSV_exit (__NR_SYSV + 1) -#define __NR_SYSV_fork (__NR_SYSV + 2) -#define __NR_SYSV_read (__NR_SYSV + 3) -#define __NR_SYSV_write (__NR_SYSV + 4) -#define __NR_SYSV_open (__NR_SYSV + 5) -#define __NR_SYSV_close (__NR_SYSV + 6) -#define __NR_SYSV_wait (__NR_SYSV + 7) -#define __NR_SYSV_creat (__NR_SYSV + 8) -#define __NR_SYSV_link (__NR_SYSV + 9) -#define __NR_SYSV_unlink (__NR_SYSV + 10) -#define __NR_SYSV_execv (__NR_SYSV + 11) -#define __NR_SYSV_chdir (__NR_SYSV + 12) -#define __NR_SYSV_time (__NR_SYSV + 13) -#define __NR_SYSV_mknod (__NR_SYSV + 14) -#define __NR_SYSV_chmod (__NR_SYSV + 15) -#define __NR_SYSV_chown (__NR_SYSV + 16) -#define __NR_SYSV_brk (__NR_SYSV + 17) -#define __NR_SYSV_stat (__NR_SYSV + 18) -#define __NR_SYSV_lseek (__NR_SYSV + 19) -#define __NR_SYSV_getpid (__NR_SYSV + 20) -#define __NR_SYSV_mount (__NR_SYSV + 21) -#define __NR_SYSV_umount (__NR_SYSV + 22) -#define __NR_SYSV_setuid (__NR_SYSV + 23) -#define __NR_SYSV_getuid (__NR_SYSV + 24) -#define __NR_SYSV_stime (__NR_SYSV + 25) -#define __NR_SYSV_ptrace (__NR_SYSV + 26) -#define __NR_SYSV_alarm (__NR_SYSV + 27) -#define __NR_SYSV_fstat (__NR_SYSV + 28) -#define __NR_SYSV_pause (__NR_SYSV + 29) -#define __NR_SYSV_utime (__NR_SYSV + 30) -#define __NR_SYSV_stty (__NR_SYSV + 31) -#define __NR_SYSV_gtty (__NR_SYSV + 32) -#define __NR_SYSV_access (__NR_SYSV + 33) -#define __NR_SYSV_nice (__NR_SYSV + 34) -#define __NR_SYSV_statfs (__NR_SYSV + 35) -#define __NR_SYSV_sync (__NR_SYSV + 36) -#define __NR_SYSV_kill (__NR_SYSV + 37) -#define __NR_SYSV_fstatfs (__NR_SYSV + 38) -#define __NR_SYSV_setpgrp (__NR_SYSV + 39) -#define __NR_SYSV_syssgi (__NR_SYSV + 40) -#define __NR_SYSV_dup (__NR_SYSV + 41) -#define __NR_SYSV_pipe (__NR_SYSV + 42) -#define __NR_SYSV_times (__NR_SYSV + 43) -#define __NR_SYSV_profil (__NR_SYSV + 44) -#define __NR_SYSV_plock (__NR_SYSV + 45) -#define __NR_SYSV_setgid (__NR_SYSV + 46) -#define __NR_SYSV_getgid (__NR_SYSV + 47) -#define __NR_SYSV_sig (__NR_SYSV + 48) -#define __NR_SYSV_msgsys (__NR_SYSV + 49) -#define __NR_SYSV_sysmips (__NR_SYSV + 50) -#define __NR_SYSV_acct (__NR_SYSV + 51) -#define __NR_SYSV_shmsys (__NR_SYSV + 52) -#define __NR_SYSV_semsys (__NR_SYSV + 53) -#define __NR_SYSV_ioctl (__NR_SYSV + 54) -#define __NR_SYSV_uadmin (__NR_SYSV + 55) -#define __NR_SYSV_sysmp (__NR_SYSV + 56) -#define __NR_SYSV_utssys (__NR_SYSV + 57) -#define __NR_SYSV_USG_reserved1 (__NR_SYSV + 58) -#define __NR_SYSV_execve (__NR_SYSV + 59) -#define __NR_SYSV_umask (__NR_SYSV + 60) -#define __NR_SYSV_chroot (__NR_SYSV + 61) -#define __NR_SYSV_fcntl (__NR_SYSV + 62) -#define __NR_SYSV_ulimit (__NR_SYSV + 63) -#define __NR_SYSV_SAFARI4_reserved1 (__NR_SYSV + 64) -#define __NR_SYSV_SAFARI4_reserved2 (__NR_SYSV + 65) -#define __NR_SYSV_SAFARI4_reserved3 (__NR_SYSV + 66) -#define __NR_SYSV_SAFARI4_reserved4 (__NR_SYSV + 67) -#define __NR_SYSV_SAFARI4_reserved5 (__NR_SYSV + 68) -#define __NR_SYSV_SAFARI4_reserved6 (__NR_SYSV + 69) -#define __NR_SYSV_advfs (__NR_SYSV + 70) -#define __NR_SYSV_unadvfs (__NR_SYSV + 71) -#define __NR_SYSV_rmount (__NR_SYSV + 72) -#define __NR_SYSV_rumount (__NR_SYSV + 73) -#define __NR_SYSV_rfstart (__NR_SYSV + 74) -#define __NR_SYSV_getrlimit64 (__NR_SYSV + 75) -#define __NR_SYSV_setrlimit64 (__NR_SYSV + 76) -#define __NR_SYSV_nanosleep (__NR_SYSV + 77) -#define __NR_SYSV_lseek64 (__NR_SYSV + 78) -#define __NR_SYSV_rmdir (__NR_SYSV + 79) -#define __NR_SYSV_mkdir (__NR_SYSV + 80) -#define __NR_SYSV_getdents (__NR_SYSV + 81) -#define __NR_SYSV_sginap (__NR_SYSV + 82) -#define __NR_SYSV_sgikopt (__NR_SYSV + 83) -#define __NR_SYSV_sysfs (__NR_SYSV + 84) -#define __NR_SYSV_getmsg (__NR_SYSV + 85) -#define __NR_SYSV_putmsg (__NR_SYSV + 86) -#define __NR_SYSV_poll (__NR_SYSV + 87) -#define __NR_SYSV_sigreturn (__NR_SYSV + 88) -#define __NR_SYSV_accept (__NR_SYSV + 89) -#define __NR_SYSV_bind (__NR_SYSV + 90) -#define __NR_SYSV_connect (__NR_SYSV + 91) -#define __NR_SYSV_gethostid (__NR_SYSV + 92) -#define __NR_SYSV_getpeername (__NR_SYSV + 93) -#define __NR_SYSV_getsockname (__NR_SYSV + 94) -#define __NR_SYSV_getsockopt (__NR_SYSV + 95) -#define __NR_SYSV_listen (__NR_SYSV + 96) -#define __NR_SYSV_recv (__NR_SYSV + 97) -#define __NR_SYSV_recvfrom (__NR_SYSV + 98) -#define __NR_SYSV_recvmsg (__NR_SYSV + 99) -#define __NR_SYSV_select (__NR_SYSV + 100) -#define __NR_SYSV_send (__NR_SYSV + 101) -#define __NR_SYSV_sendmsg (__NR_SYSV + 102) -#define __NR_SYSV_sendto (__NR_SYSV + 103) -#define __NR_SYSV_sethostid (__NR_SYSV + 104) -#define __NR_SYSV_setsockopt (__NR_SYSV + 105) -#define __NR_SYSV_shutdown (__NR_SYSV + 106) -#define __NR_SYSV_socket (__NR_SYSV + 107) -#define __NR_SYSV_gethostname (__NR_SYSV + 108) -#define __NR_SYSV_sethostname (__NR_SYSV + 109) -#define __NR_SYSV_getdomainname (__NR_SYSV + 110) -#define __NR_SYSV_setdomainname (__NR_SYSV + 111) -#define __NR_SYSV_truncate (__NR_SYSV + 112) -#define __NR_SYSV_ftruncate (__NR_SYSV + 113) -#define __NR_SYSV_rename (__NR_SYSV + 114) -#define __NR_SYSV_symlink (__NR_SYSV + 115) -#define __NR_SYSV_readlink (__NR_SYSV + 116) -#define __NR_SYSV_lstat (__NR_SYSV + 117) -#define __NR_SYSV_nfsmount (__NR_SYSV + 118) -#define __NR_SYSV_nfssvc (__NR_SYSV + 119) -#define __NR_SYSV_getfh (__NR_SYSV + 120) -#define __NR_SYSV_async_daemon (__NR_SYSV + 121) -#define __NR_SYSV_exportfs (__NR_SYSV + 122) -#define __NR_SYSV_setregid (__NR_SYSV + 123) -#define __NR_SYSV_setreuid (__NR_SYSV + 124) -#define __NR_SYSV_getitimer (__NR_SYSV + 125) -#define __NR_SYSV_setitimer (__NR_SYSV + 126) -#define __NR_SYSV_adjtime (__NR_SYSV + 127) -#define __NR_SYSV_BSD_getime (__NR_SYSV + 128) -#define __NR_SYSV_sproc (__NR_SYSV + 129) -#define __NR_SYSV_prctl (__NR_SYSV + 130) -#define __NR_SYSV_procblk (__NR_SYSV + 131) -#define __NR_SYSV_sprocsp (__NR_SYSV + 132) -#define __NR_SYSV_sgigsc (__NR_SYSV + 133) -#define __NR_SYSV_mmap (__NR_SYSV + 134) -#define __NR_SYSV_munmap (__NR_SYSV + 135) -#define __NR_SYSV_mprotect (__NR_SYSV + 136) -#define __NR_SYSV_msync (__NR_SYSV + 137) -#define __NR_SYSV_madvise (__NR_SYSV + 138) -#define __NR_SYSV_pagelock (__NR_SYSV + 139) -#define __NR_SYSV_getpagesize (__NR_SYSV + 140) -#define __NR_SYSV_quotactl (__NR_SYSV + 141) -#define __NR_SYSV_libdetach (__NR_SYSV + 142) -#define __NR_SYSV_BSDgetpgrp (__NR_SYSV + 143) -#define __NR_SYSV_BSDsetpgrp (__NR_SYSV + 144) -#define __NR_SYSV_vhangup (__NR_SYSV + 145) -#define __NR_SYSV_fsync (__NR_SYSV + 146) -#define __NR_SYSV_fchdir (__NR_SYSV + 147) -#define __NR_SYSV_getrlimit (__NR_SYSV + 148) -#define __NR_SYSV_setrlimit (__NR_SYSV + 149) -#define __NR_SYSV_cacheflush (__NR_SYSV + 150) -#define __NR_SYSV_cachectl (__NR_SYSV + 151) -#define __NR_SYSV_fchown (__NR_SYSV + 152) -#define __NR_SYSV_fchmod (__NR_SYSV + 153) -#define __NR_SYSV_wait3 (__NR_SYSV + 154) -#define __NR_SYSV_socketpair (__NR_SYSV + 155) -#define __NR_SYSV_sysinfo (__NR_SYSV + 156) -#define __NR_SYSV_nuname (__NR_SYSV + 157) -#define __NR_SYSV_xstat (__NR_SYSV + 158) -#define __NR_SYSV_lxstat (__NR_SYSV + 159) -#define __NR_SYSV_fxstat (__NR_SYSV + 160) -#define __NR_SYSV_xmknod (__NR_SYSV + 161) -#define __NR_SYSV_ksigaction (__NR_SYSV + 162) -#define __NR_SYSV_sigpending (__NR_SYSV + 163) -#define __NR_SYSV_sigprocmask (__NR_SYSV + 164) -#define __NR_SYSV_sigsuspend (__NR_SYSV + 165) -#define __NR_SYSV_sigpoll (__NR_SYSV + 166) -#define __NR_SYSV_swapctl (__NR_SYSV + 167) -#define __NR_SYSV_getcontext (__NR_SYSV + 168) -#define __NR_SYSV_setcontext (__NR_SYSV + 169) -#define __NR_SYSV_waitsys (__NR_SYSV + 170) -#define __NR_SYSV_sigstack (__NR_SYSV + 171) -#define __NR_SYSV_sigaltstack (__NR_SYSV + 172) -#define __NR_SYSV_sigsendset (__NR_SYSV + 173) -#define __NR_SYSV_statvfs (__NR_SYSV + 174) -#define __NR_SYSV_fstatvfs (__NR_SYSV + 175) -#define __NR_SYSV_getpmsg (__NR_SYSV + 176) -#define __NR_SYSV_putpmsg (__NR_SYSV + 177) -#define __NR_SYSV_lchown (__NR_SYSV + 178) -#define __NR_SYSV_priocntl (__NR_SYSV + 179) -#define __NR_SYSV_ksigqueue (__NR_SYSV + 180) -#define __NR_SYSV_readv (__NR_SYSV + 181) -#define __NR_SYSV_writev (__NR_SYSV + 182) -#define __NR_SYSV_truncate64 (__NR_SYSV + 183) -#define __NR_SYSV_ftruncate64 (__NR_SYSV + 184) -#define __NR_SYSV_mmap64 (__NR_SYSV + 185) -#define __NR_SYSV_dmi (__NR_SYSV + 186) -#define __NR_SYSV_pread (__NR_SYSV + 187) -#define __NR_SYSV_pwrite (__NR_SYSV + 188) - -/* - * BSD 4.3 syscalls are in the range from 2000 to 2999 - */ -#define __NR_BSD43 2000 -#define __NR_BSD43_syscall (__NR_BSD43 + 0) -#define __NR_BSD43_exit (__NR_BSD43 + 1) -#define __NR_BSD43_fork (__NR_BSD43 + 2) -#define __NR_BSD43_read (__NR_BSD43 + 3) -#define __NR_BSD43_write (__NR_BSD43 + 4) -#define __NR_BSD43_open (__NR_BSD43 + 5) -#define __NR_BSD43_close (__NR_BSD43 + 6) -#define __NR_BSD43_wait (__NR_BSD43 + 7) -#define __NR_BSD43_creat (__NR_BSD43 + 8) -#define __NR_BSD43_link (__NR_BSD43 + 9) -#define __NR_BSD43_unlink (__NR_BSD43 + 10) -#define __NR_BSD43_exec (__NR_BSD43 + 11) -#define __NR_BSD43_chdir (__NR_BSD43 + 12) -#define __NR_BSD43_time (__NR_BSD43 + 13) -#define __NR_BSD43_mknod (__NR_BSD43 + 14) -#define __NR_BSD43_chmod (__NR_BSD43 + 15) -#define __NR_BSD43_chown (__NR_BSD43 + 16) -#define __NR_BSD43_sbreak (__NR_BSD43 + 17) -#define __NR_BSD43_oldstat (__NR_BSD43 + 18) -#define __NR_BSD43_lseek (__NR_BSD43 + 19) -#define __NR_BSD43_getpid (__NR_BSD43 + 20) -#define __NR_BSD43_oldmount (__NR_BSD43 + 21) -#define __NR_BSD43_umount (__NR_BSD43 + 22) -#define __NR_BSD43_setuid (__NR_BSD43 + 23) -#define __NR_BSD43_getuid (__NR_BSD43 + 24) -#define __NR_BSD43_stime (__NR_BSD43 + 25) -#define __NR_BSD43_ptrace (__NR_BSD43 + 26) -#define __NR_BSD43_alarm (__NR_BSD43 + 27) -#define __NR_BSD43_oldfstat (__NR_BSD43 + 28) -#define __NR_BSD43_pause (__NR_BSD43 + 29) -#define __NR_BSD43_utime (__NR_BSD43 + 30) -#define __NR_BSD43_stty (__NR_BSD43 + 31) -#define __NR_BSD43_gtty (__NR_BSD43 + 32) -#define __NR_BSD43_access (__NR_BSD43 + 33) -#define __NR_BSD43_nice (__NR_BSD43 + 34) -#define __NR_BSD43_ftime (__NR_BSD43 + 35) -#define __NR_BSD43_sync (__NR_BSD43 + 36) -#define __NR_BSD43_kill (__NR_BSD43 + 37) -#define __NR_BSD43_stat (__NR_BSD43 + 38) -#define __NR_BSD43_oldsetpgrp (__NR_BSD43 + 39) -#define __NR_BSD43_lstat (__NR_BSD43 + 40) -#define __NR_BSD43_dup (__NR_BSD43 + 41) -#define __NR_BSD43_pipe (__NR_BSD43 + 42) -#define __NR_BSD43_times (__NR_BSD43 + 43) -#define __NR_BSD43_profil (__NR_BSD43 + 44) -#define __NR_BSD43_msgsys (__NR_BSD43 + 45) -#define __NR_BSD43_setgid (__NR_BSD43 + 46) -#define __NR_BSD43_getgid (__NR_BSD43 + 47) -#define __NR_BSD43_ssig (__NR_BSD43 + 48) -#define __NR_BSD43_reserved1 (__NR_BSD43 + 49) -#define __NR_BSD43_reserved2 (__NR_BSD43 + 50) -#define __NR_BSD43_sysacct (__NR_BSD43 + 51) -#define __NR_BSD43_phys (__NR_BSD43 + 52) -#define __NR_BSD43_lock (__NR_BSD43 + 53) -#define __NR_BSD43_ioctl (__NR_BSD43 + 54) -#define __NR_BSD43_reboot (__NR_BSD43 + 55) -#define __NR_BSD43_mpxchan (__NR_BSD43 + 56) -#define __NR_BSD43_symlink (__NR_BSD43 + 57) -#define __NR_BSD43_readlink (__NR_BSD43 + 58) -#define __NR_BSD43_execve (__NR_BSD43 + 59) -#define __NR_BSD43_umask (__NR_BSD43 + 60) -#define __NR_BSD43_chroot (__NR_BSD43 + 61) -#define __NR_BSD43_fstat (__NR_BSD43 + 62) -#define __NR_BSD43_reserved3 (__NR_BSD43 + 63) -#define __NR_BSD43_getpagesize (__NR_BSD43 + 64) -#define __NR_BSD43_mremap (__NR_BSD43 + 65) -#define __NR_BSD43_vfork (__NR_BSD43 + 66) -#define __NR_BSD43_vread (__NR_BSD43 + 67) -#define __NR_BSD43_vwrite (__NR_BSD43 + 68) -#define __NR_BSD43_sbrk (__NR_BSD43 + 69) -#define __NR_BSD43_sstk (__NR_BSD43 + 70) -#define __NR_BSD43_mmap (__NR_BSD43 + 71) -#define __NR_BSD43_vadvise (__NR_BSD43 + 72) -#define __NR_BSD43_munmap (__NR_BSD43 + 73) -#define __NR_BSD43_mprotect (__NR_BSD43 + 74) -#define __NR_BSD43_madvise (__NR_BSD43 + 75) -#define __NR_BSD43_vhangup (__NR_BSD43 + 76) -#define __NR_BSD43_vlimit (__NR_BSD43 + 77) -#define __NR_BSD43_mincore (__NR_BSD43 + 78) -#define __NR_BSD43_getgroups (__NR_BSD43 + 79) -#define __NR_BSD43_setgroups (__NR_BSD43 + 80) -#define __NR_BSD43_getpgrp (__NR_BSD43 + 81) -#define __NR_BSD43_setpgrp (__NR_BSD43 + 82) -#define __NR_BSD43_setitimer (__NR_BSD43 + 83) -#define __NR_BSD43_wait3 (__NR_BSD43 + 84) -#define __NR_BSD43_swapon (__NR_BSD43 + 85) -#define __NR_BSD43_getitimer (__NR_BSD43 + 86) -#define __NR_BSD43_gethostname (__NR_BSD43 + 87) -#define __NR_BSD43_sethostname (__NR_BSD43 + 88) -#define __NR_BSD43_getdtablesize (__NR_BSD43 + 89) -#define __NR_BSD43_dup2 (__NR_BSD43 + 90) -#define __NR_BSD43_getdopt (__NR_BSD43 + 91) -#define __NR_BSD43_fcntl (__NR_BSD43 + 92) -#define __NR_BSD43_select (__NR_BSD43 + 93) -#define __NR_BSD43_setdopt (__NR_BSD43 + 94) -#define __NR_BSD43_fsync (__NR_BSD43 + 95) -#define __NR_BSD43_setpriority (__NR_BSD43 + 96) -#define __NR_BSD43_socket (__NR_BSD43 + 97) -#define __NR_BSD43_connect (__NR_BSD43 + 98) -#define __NR_BSD43_oldaccept (__NR_BSD43 + 99) -#define __NR_BSD43_getpriority (__NR_BSD43 + 100) -#define __NR_BSD43_send (__NR_BSD43 + 101) -#define __NR_BSD43_recv (__NR_BSD43 + 102) -#define __NR_BSD43_sigreturn (__NR_BSD43 + 103) -#define __NR_BSD43_bind (__NR_BSD43 + 104) -#define __NR_BSD43_setsockopt (__NR_BSD43 + 105) -#define __NR_BSD43_listen (__NR_BSD43 + 106) -#define __NR_BSD43_vtimes (__NR_BSD43 + 107) -#define __NR_BSD43_sigvec (__NR_BSD43 + 108) -#define __NR_BSD43_sigblock (__NR_BSD43 + 109) -#define __NR_BSD43_sigsetmask (__NR_BSD43 + 110) -#define __NR_BSD43_sigpause (__NR_BSD43 + 111) -#define __NR_BSD43_sigstack (__NR_BSD43 + 112) -#define __NR_BSD43_oldrecvmsg (__NR_BSD43 + 113) -#define __NR_BSD43_oldsendmsg (__NR_BSD43 + 114) -#define __NR_BSD43_vtrace (__NR_BSD43 + 115) -#define __NR_BSD43_gettimeofday (__NR_BSD43 + 116) -#define __NR_BSD43_getrusage (__NR_BSD43 + 117) -#define __NR_BSD43_getsockopt (__NR_BSD43 + 118) -#define __NR_BSD43_reserved4 (__NR_BSD43 + 119) -#define __NR_BSD43_readv (__NR_BSD43 + 120) -#define __NR_BSD43_writev (__NR_BSD43 + 121) -#define __NR_BSD43_settimeofday (__NR_BSD43 + 122) -#define __NR_BSD43_fchown (__NR_BSD43 + 123) -#define __NR_BSD43_fchmod (__NR_BSD43 + 124) -#define __NR_BSD43_oldrecvfrom (__NR_BSD43 + 125) -#define __NR_BSD43_setreuid (__NR_BSD43 + 126) -#define __NR_BSD43_setregid (__NR_BSD43 + 127) -#define __NR_BSD43_rename (__NR_BSD43 + 128) -#define __NR_BSD43_truncate (__NR_BSD43 + 129) -#define __NR_BSD43_ftruncate (__NR_BSD43 + 130) -#define __NR_BSD43_flock (__NR_BSD43 + 131) -#define __NR_BSD43_semsys (__NR_BSD43 + 132) -#define __NR_BSD43_sendto (__NR_BSD43 + 133) -#define __NR_BSD43_shutdown (__NR_BSD43 + 134) -#define __NR_BSD43_socketpair (__NR_BSD43 + 135) -#define __NR_BSD43_mkdir (__NR_BSD43 + 136) -#define __NR_BSD43_rmdir (__NR_BSD43 + 137) -#define __NR_BSD43_utimes (__NR_BSD43 + 138) -#define __NR_BSD43_sigcleanup (__NR_BSD43 + 139) -#define __NR_BSD43_adjtime (__NR_BSD43 + 140) -#define __NR_BSD43_oldgetpeername (__NR_BSD43 + 141) -#define __NR_BSD43_gethostid (__NR_BSD43 + 142) -#define __NR_BSD43_sethostid (__NR_BSD43 + 143) -#define __NR_BSD43_getrlimit (__NR_BSD43 + 144) -#define __NR_BSD43_setrlimit (__NR_BSD43 + 145) -#define __NR_BSD43_killpg (__NR_BSD43 + 146) -#define __NR_BSD43_shmsys (__NR_BSD43 + 147) -#define __NR_BSD43_quota (__NR_BSD43 + 148) -#define __NR_BSD43_qquota (__NR_BSD43 + 149) -#define __NR_BSD43_oldgetsockname (__NR_BSD43 + 150) -#define __NR_BSD43_sysmips (__NR_BSD43 + 151) -#define __NR_BSD43_cacheflush (__NR_BSD43 + 152) -#define __NR_BSD43_cachectl (__NR_BSD43 + 153) -#define __NR_BSD43_debug (__NR_BSD43 + 154) -#define __NR_BSD43_reserved5 (__NR_BSD43 + 155) -#define __NR_BSD43_reserved6 (__NR_BSD43 + 156) -#define __NR_BSD43_nfs_mount (__NR_BSD43 + 157) -#define __NR_BSD43_nfs_svc (__NR_BSD43 + 158) -#define __NR_BSD43_getdirentries (__NR_BSD43 + 159) -#define __NR_BSD43_statfs (__NR_BSD43 + 160) -#define __NR_BSD43_fstatfs (__NR_BSD43 + 161) -#define __NR_BSD43_unmount (__NR_BSD43 + 162) -#define __NR_BSD43_async_daemon (__NR_BSD43 + 163) -#define __NR_BSD43_nfs_getfh (__NR_BSD43 + 164) -#define __NR_BSD43_getdomainname (__NR_BSD43 + 165) -#define __NR_BSD43_setdomainname (__NR_BSD43 + 166) -#define __NR_BSD43_pcfs_mount (__NR_BSD43 + 167) -#define __NR_BSD43_quotactl (__NR_BSD43 + 168) -#define __NR_BSD43_oldexportfs (__NR_BSD43 + 169) -#define __NR_BSD43_smount (__NR_BSD43 + 170) -#define __NR_BSD43_mipshwconf (__NR_BSD43 + 171) -#define __NR_BSD43_exportfs (__NR_BSD43 + 172) -#define __NR_BSD43_nfsfh_open (__NR_BSD43 + 173) -#define __NR_BSD43_libattach (__NR_BSD43 + 174) -#define __NR_BSD43_libdetach (__NR_BSD43 + 175) -#define __NR_BSD43_accept (__NR_BSD43 + 176) -#define __NR_BSD43_reserved7 (__NR_BSD43 + 177) -#define __NR_BSD43_reserved8 (__NR_BSD43 + 178) -#define __NR_BSD43_recvmsg (__NR_BSD43 + 179) -#define __NR_BSD43_recvfrom (__NR_BSD43 + 180) -#define __NR_BSD43_sendmsg (__NR_BSD43 + 181) -#define __NR_BSD43_getpeername (__NR_BSD43 + 182) -#define __NR_BSD43_getsockname (__NR_BSD43 + 183) -#define __NR_BSD43_aread (__NR_BSD43 + 184) -#define __NR_BSD43_awrite (__NR_BSD43 + 185) -#define __NR_BSD43_listio (__NR_BSD43 + 186) -#define __NR_BSD43_acancel (__NR_BSD43 + 187) -#define __NR_BSD43_astatus (__NR_BSD43 + 188) -#define __NR_BSD43_await (__NR_BSD43 + 189) -#define __NR_BSD43_areadv (__NR_BSD43 + 190) -#define __NR_BSD43_awritev (__NR_BSD43 + 191) - -/* - * POSIX syscalls are in the range from 3000 to 3999 - */ -#define __NR_POSIX 3000 -#define __NR_POSIX_syscall (__NR_POSIX + 0) -#define __NR_POSIX_exit (__NR_POSIX + 1) -#define __NR_POSIX_fork (__NR_POSIX + 2) -#define __NR_POSIX_read (__NR_POSIX + 3) -#define __NR_POSIX_write (__NR_POSIX + 4) -#define __NR_POSIX_open (__NR_POSIX + 5) -#define __NR_POSIX_close (__NR_POSIX + 6) -#define __NR_POSIX_wait (__NR_POSIX + 7) -#define __NR_POSIX_creat (__NR_POSIX + 8) -#define __NR_POSIX_link (__NR_POSIX + 9) -#define __NR_POSIX_unlink (__NR_POSIX + 10) -#define __NR_POSIX_exec (__NR_POSIX + 11) -#define __NR_POSIX_chdir (__NR_POSIX + 12) -#define __NR_POSIX_gtime (__NR_POSIX + 13) -#define __NR_POSIX_mknod (__NR_POSIX + 14) -#define __NR_POSIX_chmod (__NR_POSIX + 15) -#define __NR_POSIX_chown (__NR_POSIX + 16) -#define __NR_POSIX_sbreak (__NR_POSIX + 17) -#define __NR_POSIX_stat (__NR_POSIX + 18) -#define __NR_POSIX_lseek (__NR_POSIX + 19) -#define __NR_POSIX_getpid (__NR_POSIX + 20) -#define __NR_POSIX_mount (__NR_POSIX + 21) -#define __NR_POSIX_umount (__NR_POSIX + 22) -#define __NR_POSIX_setuid (__NR_POSIX + 23) -#define __NR_POSIX_getuid (__NR_POSIX + 24) -#define __NR_POSIX_stime (__NR_POSIX + 25) -#define __NR_POSIX_ptrace (__NR_POSIX + 26) -#define __NR_POSIX_alarm (__NR_POSIX + 27) -#define __NR_POSIX_fstat (__NR_POSIX + 28) -#define __NR_POSIX_pause (__NR_POSIX + 29) -#define __NR_POSIX_utime (__NR_POSIX + 30) -#define __NR_POSIX_stty (__NR_POSIX + 31) -#define __NR_POSIX_gtty (__NR_POSIX + 32) -#define __NR_POSIX_access (__NR_POSIX + 33) -#define __NR_POSIX_nice (__NR_POSIX + 34) -#define __NR_POSIX_statfs (__NR_POSIX + 35) -#define __NR_POSIX_sync (__NR_POSIX + 36) -#define __NR_POSIX_kill (__NR_POSIX + 37) -#define __NR_POSIX_fstatfs (__NR_POSIX + 38) -#define __NR_POSIX_getpgrp (__NR_POSIX + 39) -#define __NR_POSIX_syssgi (__NR_POSIX + 40) -#define __NR_POSIX_dup (__NR_POSIX + 41) -#define __NR_POSIX_pipe (__NR_POSIX + 42) -#define __NR_POSIX_times (__NR_POSIX + 43) -#define __NR_POSIX_profil (__NR_POSIX + 44) -#define __NR_POSIX_lock (__NR_POSIX + 45) -#define __NR_POSIX_setgid (__NR_POSIX + 46) -#define __NR_POSIX_getgid (__NR_POSIX + 47) -#define __NR_POSIX_sig (__NR_POSIX + 48) -#define __NR_POSIX_msgsys (__NR_POSIX + 49) -#define __NR_POSIX_sysmips (__NR_POSIX + 50) -#define __NR_POSIX_sysacct (__NR_POSIX + 51) -#define __NR_POSIX_shmsys (__NR_POSIX + 52) -#define __NR_POSIX_semsys (__NR_POSIX + 53) -#define __NR_POSIX_ioctl (__NR_POSIX + 54) -#define __NR_POSIX_uadmin (__NR_POSIX + 55) -#define __NR_POSIX_exch (__NR_POSIX + 56) -#define __NR_POSIX_utssys (__NR_POSIX + 57) -#define __NR_POSIX_USG_reserved1 (__NR_POSIX + 58) -#define __NR_POSIX_exece (__NR_POSIX + 59) -#define __NR_POSIX_umask (__NR_POSIX + 60) -#define __NR_POSIX_chroot (__NR_POSIX + 61) -#define __NR_POSIX_fcntl (__NR_POSIX + 62) -#define __NR_POSIX_ulimit (__NR_POSIX + 63) -#define __NR_POSIX_SAFARI4_reserved1 (__NR_POSIX + 64) -#define __NR_POSIX_SAFARI4_reserved2 (__NR_POSIX + 65) -#define __NR_POSIX_SAFARI4_reserved3 (__NR_POSIX + 66) -#define __NR_POSIX_SAFARI4_reserved4 (__NR_POSIX + 67) -#define __NR_POSIX_SAFARI4_reserved5 (__NR_POSIX + 68) -#define __NR_POSIX_SAFARI4_reserved6 (__NR_POSIX + 69) -#define __NR_POSIX_advfs (__NR_POSIX + 70) -#define __NR_POSIX_unadvfs (__NR_POSIX + 71) -#define __NR_POSIX_rmount (__NR_POSIX + 72) -#define __NR_POSIX_rumount (__NR_POSIX + 73) -#define __NR_POSIX_rfstart (__NR_POSIX + 74) -#define __NR_POSIX_reserved1 (__NR_POSIX + 75) -#define __NR_POSIX_rdebug (__NR_POSIX + 76) -#define __NR_POSIX_rfstop (__NR_POSIX + 77) -#define __NR_POSIX_rfsys (__NR_POSIX + 78) -#define __NR_POSIX_rmdir (__NR_POSIX + 79) -#define __NR_POSIX_mkdir (__NR_POSIX + 80) -#define __NR_POSIX_getdents (__NR_POSIX + 81) -#define __NR_POSIX_sginap (__NR_POSIX + 82) -#define __NR_POSIX_sgikopt (__NR_POSIX + 83) -#define __NR_POSIX_sysfs (__NR_POSIX + 84) -#define __NR_POSIX_getmsg (__NR_POSIX + 85) -#define __NR_POSIX_putmsg (__NR_POSIX + 86) -#define __NR_POSIX_poll (__NR_POSIX + 87) -#define __NR_POSIX_sigreturn (__NR_POSIX + 88) -#define __NR_POSIX_accept (__NR_POSIX + 89) -#define __NR_POSIX_bind (__NR_POSIX + 90) -#define __NR_POSIX_connect (__NR_POSIX + 91) -#define __NR_POSIX_gethostid (__NR_POSIX + 92) -#define __NR_POSIX_getpeername (__NR_POSIX + 93) -#define __NR_POSIX_getsockname (__NR_POSIX + 94) -#define __NR_POSIX_getsockopt (__NR_POSIX + 95) -#define __NR_POSIX_listen (__NR_POSIX + 96) -#define __NR_POSIX_recv (__NR_POSIX + 97) -#define __NR_POSIX_recvfrom (__NR_POSIX + 98) -#define __NR_POSIX_recvmsg (__NR_POSIX + 99) -#define __NR_POSIX_select (__NR_POSIX + 100) -#define __NR_POSIX_send (__NR_POSIX + 101) -#define __NR_POSIX_sendmsg (__NR_POSIX + 102) -#define __NR_POSIX_sendto (__NR_POSIX + 103) -#define __NR_POSIX_sethostid (__NR_POSIX + 104) -#define __NR_POSIX_setsockopt (__NR_POSIX + 105) -#define __NR_POSIX_shutdown (__NR_POSIX + 106) -#define __NR_POSIX_socket (__NR_POSIX + 107) -#define __NR_POSIX_gethostname (__NR_POSIX + 108) -#define __NR_POSIX_sethostname (__NR_POSIX + 109) -#define __NR_POSIX_getdomainname (__NR_POSIX + 110) -#define __NR_POSIX_setdomainname (__NR_POSIX + 111) -#define __NR_POSIX_truncate (__NR_POSIX + 112) -#define __NR_POSIX_ftruncate (__NR_POSIX + 113) -#define __NR_POSIX_rename (__NR_POSIX + 114) -#define __NR_POSIX_symlink (__NR_POSIX + 115) -#define __NR_POSIX_readlink (__NR_POSIX + 116) -#define __NR_POSIX_lstat (__NR_POSIX + 117) -#define __NR_POSIX_nfs_mount (__NR_POSIX + 118) -#define __NR_POSIX_nfs_svc (__NR_POSIX + 119) -#define __NR_POSIX_nfs_getfh (__NR_POSIX + 120) -#define __NR_POSIX_async_daemon (__NR_POSIX + 121) -#define __NR_POSIX_exportfs (__NR_POSIX + 122) -#define __NR_POSIX_SGI_setregid (__NR_POSIX + 123) -#define __NR_POSIX_SGI_setreuid (__NR_POSIX + 124) -#define __NR_POSIX_getitimer (__NR_POSIX + 125) -#define __NR_POSIX_setitimer (__NR_POSIX + 126) -#define __NR_POSIX_adjtime (__NR_POSIX + 127) -#define __NR_POSIX_SGI_bsdgettime (__NR_POSIX + 128) -#define __NR_POSIX_SGI_sproc (__NR_POSIX + 129) -#define __NR_POSIX_SGI_prctl (__NR_POSIX + 130) -#define __NR_POSIX_SGI_blkproc (__NR_POSIX + 131) -#define __NR_POSIX_SGI_reserved1 (__NR_POSIX + 132) -#define __NR_POSIX_SGI_sgigsc (__NR_POSIX + 133) -#define __NR_POSIX_SGI_mmap (__NR_POSIX + 134) -#define __NR_POSIX_SGI_munmap (__NR_POSIX + 135) -#define __NR_POSIX_SGI_mprotect (__NR_POSIX + 136) -#define __NR_POSIX_SGI_msync (__NR_POSIX + 137) -#define __NR_POSIX_SGI_madvise (__NR_POSIX + 138) -#define __NR_POSIX_SGI_mpin (__NR_POSIX + 139) -#define __NR_POSIX_SGI_getpagesize (__NR_POSIX + 140) -#define __NR_POSIX_SGI_libattach (__NR_POSIX + 141) -#define __NR_POSIX_SGI_libdetach (__NR_POSIX + 142) -#define __NR_POSIX_SGI_getpgrp (__NR_POSIX + 143) -#define __NR_POSIX_SGI_setpgrp (__NR_POSIX + 144) -#define __NR_POSIX_SGI_reserved2 (__NR_POSIX + 145) -#define __NR_POSIX_SGI_reserved3 (__NR_POSIX + 146) -#define __NR_POSIX_SGI_reserved4 (__NR_POSIX + 147) -#define __NR_POSIX_SGI_reserved5 (__NR_POSIX + 148) -#define __NR_POSIX_SGI_reserved6 (__NR_POSIX + 149) -#define __NR_POSIX_cacheflush (__NR_POSIX + 150) -#define __NR_POSIX_cachectl (__NR_POSIX + 151) -#define __NR_POSIX_fchown (__NR_POSIX + 152) -#define __NR_POSIX_fchmod (__NR_POSIX + 153) -#define __NR_POSIX_wait3 (__NR_POSIX + 154) -#define __NR_POSIX_mmap (__NR_POSIX + 155) -#define __NR_POSIX_munmap (__NR_POSIX + 156) -#define __NR_POSIX_madvise (__NR_POSIX + 157) -#define __NR_POSIX_BSD_getpagesize (__NR_POSIX + 158) -#define __NR_POSIX_setreuid (__NR_POSIX + 159) -#define __NR_POSIX_setregid (__NR_POSIX + 160) -#define __NR_POSIX_setpgid (__NR_POSIX + 161) -#define __NR_POSIX_getgroups (__NR_POSIX + 162) -#define __NR_POSIX_setgroups (__NR_POSIX + 163) -#define __NR_POSIX_gettimeofday (__NR_POSIX + 164) -#define __NR_POSIX_getrusage (__NR_POSIX + 165) -#define __NR_POSIX_getrlimit (__NR_POSIX + 166) -#define __NR_POSIX_setrlimit (__NR_POSIX + 167) -#define __NR_POSIX_waitpid (__NR_POSIX + 168) -#define __NR_POSIX_dup2 (__NR_POSIX + 169) -#define __NR_POSIX_reserved2 (__NR_POSIX + 170) -#define __NR_POSIX_reserved3 (__NR_POSIX + 171) -#define __NR_POSIX_reserved4 (__NR_POSIX + 172) -#define __NR_POSIX_reserved5 (__NR_POSIX + 173) -#define __NR_POSIX_reserved6 (__NR_POSIX + 174) -#define __NR_POSIX_reserved7 (__NR_POSIX + 175) -#define __NR_POSIX_reserved8 (__NR_POSIX + 176) -#define __NR_POSIX_reserved9 (__NR_POSIX + 177) -#define __NR_POSIX_reserved10 (__NR_POSIX + 178) -#define __NR_POSIX_reserved11 (__NR_POSIX + 179) -#define __NR_POSIX_reserved12 (__NR_POSIX + 180) -#define __NR_POSIX_reserved13 (__NR_POSIX + 181) -#define __NR_POSIX_reserved14 (__NR_POSIX + 182) -#define __NR_POSIX_reserved15 (__NR_POSIX + 183) -#define __NR_POSIX_reserved16 (__NR_POSIX + 184) -#define __NR_POSIX_reserved17 (__NR_POSIX + 185) -#define __NR_POSIX_reserved18 (__NR_POSIX + 186) -#define __NR_POSIX_reserved19 (__NR_POSIX + 187) -#define __NR_POSIX_reserved20 (__NR_POSIX + 188) -#define __NR_POSIX_reserved21 (__NR_POSIX + 189) -#define __NR_POSIX_reserved22 (__NR_POSIX + 190) -#define __NR_POSIX_reserved23 (__NR_POSIX + 191) -#define __NR_POSIX_reserved24 (__NR_POSIX + 192) -#define __NR_POSIX_reserved25 (__NR_POSIX + 193) -#define __NR_POSIX_reserved26 (__NR_POSIX + 194) -#define __NR_POSIX_reserved27 (__NR_POSIX + 195) -#define __NR_POSIX_reserved28 (__NR_POSIX + 196) -#define __NR_POSIX_reserved29 (__NR_POSIX + 197) -#define __NR_POSIX_reserved30 (__NR_POSIX + 198) -#define __NR_POSIX_reserved31 (__NR_POSIX + 199) -#define __NR_POSIX_reserved32 (__NR_POSIX + 200) -#define __NR_POSIX_reserved33 (__NR_POSIX + 201) -#define __NR_POSIX_reserved34 (__NR_POSIX + 202) -#define __NR_POSIX_reserved35 (__NR_POSIX + 203) -#define __NR_POSIX_reserved36 (__NR_POSIX + 204) -#define __NR_POSIX_reserved37 (__NR_POSIX + 205) -#define __NR_POSIX_reserved38 (__NR_POSIX + 206) -#define __NR_POSIX_reserved39 (__NR_POSIX + 207) -#define __NR_POSIX_reserved40 (__NR_POSIX + 208) -#define __NR_POSIX_reserved41 (__NR_POSIX + 209) -#define __NR_POSIX_reserved42 (__NR_POSIX + 210) -#define __NR_POSIX_reserved43 (__NR_POSIX + 211) -#define __NR_POSIX_reserved44 (__NR_POSIX + 212) -#define __NR_POSIX_reserved45 (__NR_POSIX + 213) -#define __NR_POSIX_reserved46 (__NR_POSIX + 214) -#define __NR_POSIX_reserved47 (__NR_POSIX + 215) -#define __NR_POSIX_reserved48 (__NR_POSIX + 216) -#define __NR_POSIX_reserved49 (__NR_POSIX + 217) -#define __NR_POSIX_reserved50 (__NR_POSIX + 218) -#define __NR_POSIX_reserved51 (__NR_POSIX + 219) -#define __NR_POSIX_reserved52 (__NR_POSIX + 220) -#define __NR_POSIX_reserved53 (__NR_POSIX + 221) -#define __NR_POSIX_reserved54 (__NR_POSIX + 222) -#define __NR_POSIX_reserved55 (__NR_POSIX + 223) -#define __NR_POSIX_reserved56 (__NR_POSIX + 224) -#define __NR_POSIX_reserved57 (__NR_POSIX + 225) -#define __NR_POSIX_reserved58 (__NR_POSIX + 226) -#define __NR_POSIX_reserved59 (__NR_POSIX + 227) -#define __NR_POSIX_reserved60 (__NR_POSIX + 228) -#define __NR_POSIX_reserved61 (__NR_POSIX + 229) -#define __NR_POSIX_reserved62 (__NR_POSIX + 230) -#define __NR_POSIX_reserved63 (__NR_POSIX + 231) -#define __NR_POSIX_reserved64 (__NR_POSIX + 232) -#define __NR_POSIX_reserved65 (__NR_POSIX + 233) -#define __NR_POSIX_reserved66 (__NR_POSIX + 234) -#define __NR_POSIX_reserved67 (__NR_POSIX + 235) -#define __NR_POSIX_reserved68 (__NR_POSIX + 236) -#define __NR_POSIX_reserved69 (__NR_POSIX + 237) -#define __NR_POSIX_reserved70 (__NR_POSIX + 238) -#define __NR_POSIX_reserved71 (__NR_POSIX + 239) -#define __NR_POSIX_reserved72 (__NR_POSIX + 240) -#define __NR_POSIX_reserved73 (__NR_POSIX + 241) -#define __NR_POSIX_reserved74 (__NR_POSIX + 242) -#define __NR_POSIX_reserved75 (__NR_POSIX + 243) -#define __NR_POSIX_reserved76 (__NR_POSIX + 244) -#define __NR_POSIX_reserved77 (__NR_POSIX + 245) -#define __NR_POSIX_reserved78 (__NR_POSIX + 246) -#define __NR_POSIX_reserved79 (__NR_POSIX + 247) -#define __NR_POSIX_reserved80 (__NR_POSIX + 248) -#define __NR_POSIX_reserved81 (__NR_POSIX + 249) -#define __NR_POSIX_reserved82 (__NR_POSIX + 250) -#define __NR_POSIX_reserved83 (__NR_POSIX + 251) -#define __NR_POSIX_reserved84 (__NR_POSIX + 252) -#define __NR_POSIX_reserved85 (__NR_POSIX + 253) -#define __NR_POSIX_reserved86 (__NR_POSIX + 254) -#define __NR_POSIX_reserved87 (__NR_POSIX + 255) -#define __NR_POSIX_reserved88 (__NR_POSIX + 256) -#define __NR_POSIX_reserved89 (__NR_POSIX + 257) -#define __NR_POSIX_reserved90 (__NR_POSIX + 258) -#define __NR_POSIX_reserved91 (__NR_POSIX + 259) -#define __NR_POSIX_netboot (__NR_POSIX + 260) -#define __NR_POSIX_netunboot (__NR_POSIX + 261) -#define __NR_POSIX_rdump (__NR_POSIX + 262) -#define __NR_POSIX_setsid (__NR_POSIX + 263) -#define __NR_POSIX_getmaxsig (__NR_POSIX + 264) -#define __NR_POSIX_sigpending (__NR_POSIX + 265) -#define __NR_POSIX_sigprocmask (__NR_POSIX + 266) -#define __NR_POSIX_sigsuspend (__NR_POSIX + 267) -#define __NR_POSIX_sigaction (__NR_POSIX + 268) -#define __NR_POSIX_MIPS_reserved1 (__NR_POSIX + 269) -#define __NR_POSIX_MIPS_reserved2 (__NR_POSIX + 270) -#define __NR_POSIX_MIPS_reserved3 (__NR_POSIX + 271) -#define __NR_POSIX_MIPS_reserved4 (__NR_POSIX + 272) -#define __NR_POSIX_MIPS_reserved5 (__NR_POSIX + 273) -#define __NR_POSIX_MIPS_reserved6 (__NR_POSIX + 274) -#define __NR_POSIX_MIPS_reserved7 (__NR_POSIX + 275) -#define __NR_POSIX_MIPS_reserved8 (__NR_POSIX + 276) -#define __NR_POSIX_MIPS_reserved9 (__NR_POSIX + 277) -#define __NR_POSIX_MIPS_reserved10 (__NR_POSIX + 278) -#define __NR_POSIX_MIPS_reserved11 (__NR_POSIX + 279) -#define __NR_POSIX_TANDEM_reserved1 (__NR_POSIX + 280) -#define __NR_POSIX_TANDEM_reserved2 (__NR_POSIX + 281) -#define __NR_POSIX_TANDEM_reserved3 (__NR_POSIX + 282) -#define __NR_POSIX_TANDEM_reserved4 (__NR_POSIX + 283) -#define __NR_POSIX_TANDEM_reserved5 (__NR_POSIX + 284) -#define __NR_POSIX_TANDEM_reserved6 (__NR_POSIX + 285) -#define __NR_POSIX_TANDEM_reserved7 (__NR_POSIX + 286) -#define __NR_POSIX_TANDEM_reserved8 (__NR_POSIX + 287) -#define __NR_POSIX_TANDEM_reserved9 (__NR_POSIX + 288) -#define __NR_POSIX_TANDEM_reserved10 (__NR_POSIX + 289) -#define __NR_POSIX_TANDEM_reserved11 (__NR_POSIX + 290) -#define __NR_POSIX_TANDEM_reserved12 (__NR_POSIX + 291) -#define __NR_POSIX_TANDEM_reserved13 (__NR_POSIX + 292) -#define __NR_POSIX_TANDEM_reserved14 (__NR_POSIX + 293) -#define __NR_POSIX_TANDEM_reserved15 (__NR_POSIX + 294) -#define __NR_POSIX_TANDEM_reserved16 (__NR_POSIX + 295) -#define __NR_POSIX_TANDEM_reserved17 (__NR_POSIX + 296) -#define __NR_POSIX_TANDEM_reserved18 (__NR_POSIX + 297) -#define __NR_POSIX_TANDEM_reserved19 (__NR_POSIX + 298) -#define __NR_POSIX_TANDEM_reserved20 (__NR_POSIX + 299) -#define __NR_POSIX_SGI_reserved7 (__NR_POSIX + 300) -#define __NR_POSIX_SGI_reserved8 (__NR_POSIX + 301) -#define __NR_POSIX_SGI_reserved9 (__NR_POSIX + 302) -#define __NR_POSIX_SGI_reserved10 (__NR_POSIX + 303) -#define __NR_POSIX_SGI_reserved11 (__NR_POSIX + 304) -#define __NR_POSIX_SGI_reserved12 (__NR_POSIX + 305) -#define __NR_POSIX_SGI_reserved13 (__NR_POSIX + 306) -#define __NR_POSIX_SGI_reserved14 (__NR_POSIX + 307) -#define __NR_POSIX_SGI_reserved15 (__NR_POSIX + 308) -#define __NR_POSIX_SGI_reserved16 (__NR_POSIX + 309) -#define __NR_POSIX_SGI_reserved17 (__NR_POSIX + 310) -#define __NR_POSIX_SGI_reserved18 (__NR_POSIX + 311) -#define __NR_POSIX_SGI_reserved19 (__NR_POSIX + 312) -#define __NR_POSIX_SGI_reserved20 (__NR_POSIX + 313) -#define __NR_POSIX_SGI_reserved21 (__NR_POSIX + 314) -#define __NR_POSIX_SGI_reserved22 (__NR_POSIX + 315) -#define __NR_POSIX_SGI_reserved23 (__NR_POSIX + 316) -#define __NR_POSIX_SGI_reserved24 (__NR_POSIX + 317) -#define __NR_POSIX_SGI_reserved25 (__NR_POSIX + 318) -#define __NR_POSIX_SGI_reserved26 (__NR_POSIX + 319) - -#endif /* _ASM_RISCOS_SYSCALL_H */ From arnaud.giersch@free.fr Sat Nov 12 23:36:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 23:36:53 +0000 (GMT) Received: from smtp5-g19.free.fr ([212.27.42.35]:17132 "EHLO smtp5-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8133893AbVKLXgf (ORCPT ); Sat, 12 Nov 2005 23:36:35 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp5-g19.free.fr (Postfix) with ESMTP id 119E19631; Sun, 13 Nov 2005 00:38:19 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1Eb4ws-0003IS-Fk; Sun, 13 Nov 2005 00:38:18 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1Eb4ws-000071-0L; Sun, 13 Nov 2005 00:38:18 +0100 To: ralf@linux-mips.org Subject: [PATCH] Export IP32 mace symbol Cc: linux-mips@linux-mips.org Message-Id: From: Arnaud Giersch Date: Sun, 13 Nov 2005 00:38:18 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Export mace symbol so that it can be used in modules. Signed-off-by: Arnaud Giersch --- Ralf, you told me that this was OK but you did not committed it. crime.c | 3 +++ 1 files changed, 3 insertions(+) diff --git a/arch/mips/sgi-ip32/crime.c b/arch/mips/sgi-ip32/crime.c --- a/arch/mips/sgi-ip32/crime.c +++ b/arch/mips/sgi-ip32/crime.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -21,6 +22,8 @@ struct sgi_crime *crime; struct sgi_mace *mace; +EXPORT_SYMBOL_GPL(mace); + void __init crime_init(void) { unsigned int id, rev; From arnaud.giersch@free.fr Sat Nov 12 23:37:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 23:37:41 +0000 (GMT) Received: from smtp6-g19.free.fr ([212.27.42.36]:2528 "EHLO smtp6-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8133894AbVKLXgg (ORCPT ); Sat, 12 Nov 2005 23:36:36 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp6-g19.free.fr (Postfix) with ESMTP id 1D3B99544; Sun, 13 Nov 2005 00:38:19 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1Eb4ws-0003IT-GO; Sun, 13 Nov 2005 00:38:18 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1Eb4ws-000076-3T; Sun, 13 Nov 2005 00:38:18 +0100 To: ralf@linux-mips.org Subject: [PATCH] Fix and complete IP32 parport definitions Cc: linux-mips@linux-mips.org Message-Id: From: Arnaud Giersch Date: Sun, 13 Nov 2005 00:38:18 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Fix, complete, and indent IP32 parport definitions. Definition were wrong for CTXINUSE and DMACTIVE (1-bit shift). Add macros DATA_BOUND, DATALEN_SHIFT, and CTRSHIFT. Signed-off-by: Arnaud Giersch --- mace.h | 42 ++++++++++++++++++++++++++---------------- 1 files changed, 26 insertions(+), 16 deletions(-) diff --git a/include/asm-mips/ip32/mace.h b/include/asm-mips/ip32/mace.h --- a/include/asm-mips/ip32/mace.h +++ b/include/asm-mips/ip32/mace.h @@ -150,24 +150,34 @@ struct mace_audio { /* register definitions for parallel port DMA */ struct mace_parport { -/* 0 - do nothing, 1 - pulse terminal count to the device after buffer is drained */ -#define MACEPAR_CONTEXT_LASTFLAG BIT(63) -/* Should not cross 4K page boundary */ -#define MACEPAR_CONTEXT_DATALEN_MASK 0xfff00000000 -/* Can be arbitrarily aligned on any byte boundary on output, 64 byte aligned on input */ -#define MACEPAR_CONTEXT_BASEADDR_MASK 0xffffffff + /* 0 - do nothing, + * 1 - pulse terminal count to the device after buffer is drained */ +#define MACEPAR_CONTEXT_LASTFLAG BIT(63) + /* Should not cross 4K page boundary */ +#define MACEPAR_CONTEXT_DATA_BOUND 0x0000000000001000UL +#define MACEPAR_CONTEXT_DATALEN_MASK 0x00000fff00000000UL +#define MACEPAR_CONTEXT_DATALEN_SHIFT 32 + /* Can be arbitrarily aligned on any byte boundary on output, + * 64 byte aligned on input */ +#define MACEPAR_CONTEXT_BASEADDR_MASK 0x00000000ffffffffUL volatile u64 context_a; volatile u64 context_b; -#define MACEPAR_CTLSTAT_DIRECTION BIT(0) /* 0 - mem->device, 1 - device->mem */ -#define MACEPAR_CTLSTAT_ENABLE BIT(1) /* 0 - channel frozen, 1 - channel enabled */ -#define MACEPAR_CTLSTAT_RESET BIT(2) /* 0 - channel active, 1 - complete channel reset */ -#define MACEPAR_CTLSTAT_CTXB_VALID BIT(3) -#define MACEPAR_CTLSTAT_CTXA_VALID BIT(4) - volatile u64 cntlstat; /* Control/Status register */ -#define MACEPAR_DIAG_CTXINUSE BIT(1) -#define MACEPAR_DIAG_DMACTIVE BIT(2) /* 1 - Dma engine is enabled and processing something */ -#define MACEPAR_DIAG_CTRMASK 0x3ffc /* Counter of bytes left */ - volatile u64 diagnostic; /* RO: diagnostic register */ + /* 0 - mem->device, 1 - device->mem */ +#define MACEPAR_CTLSTAT_DIRECTION BIT(0) + /* 0 - channel frozen, 1 - channel enabled */ +#define MACEPAR_CTLSTAT_ENABLE BIT(1) + /* 0 - channel active, 1 - complete channel reset */ +#define MACEPAR_CTLSTAT_RESET BIT(2) +#define MACEPAR_CTLSTAT_CTXB_VALID BIT(3) +#define MACEPAR_CTLSTAT_CTXA_VALID BIT(4) + volatile u64 cntlstat; /* Control/Status register */ +#define MACEPAR_DIAG_CTXINUSE BIT(0) + /* 1 - Dma engine is enabled and processing something */ +#define MACEPAR_DIAG_DMACTIVE BIT(1) + /* Counter of bytes left */ +#define MACEPAR_DIAG_CTRMASK 0x0000000000003ffcUL +#define MACEPAR_DIAG_CTRSHIFT 2 + volatile u64 diagnostic; /* RO: diagnostic register */ }; /* ISA Control and DMA registers */ From arnaud.giersch@free.fr Sat Nov 12 23:38:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 23:38:32 +0000 (GMT) Received: from smtp2-g19.free.fr ([212.27.42.28]:15233 "EHLO smtp2-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8136299AbVKLXgi (ORCPT ); Sat, 12 Nov 2005 23:36:38 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp2-g19.free.fr (Postfix) with ESMTP id 955EF522EC; Sun, 13 Nov 2005 00:38:19 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1Eb4ws-0003IU-G4; Sun, 13 Nov 2005 00:38:18 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1Eb4ws-00007B-6U; Sun, 13 Nov 2005 00:38:18 +0100 To: ralf@linux-mips.org Subject: [PATCH] Fix IP32 sparse warnings Cc: linux-mips@linux-mips.org Message-Id: From: Arnaud Giersch Date: Sun, 13 Nov 2005 00:38:18 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Add __iomem qualifier to crime and mace pointers. Signed-off-by: Arnaud Giersch --- I passed my code through sparse and got some warnings. arch/mips/sgi-ip32/crime.c | 4 ++-- include/asm-mips/ip32/crime.h | 2 +- include/asm-mips/ip32/mace.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/mips/sgi-ip32/crime.c b/arch/mips/sgi-ip32/crime.c --- a/arch/mips/sgi-ip32/crime.c +++ b/arch/mips/sgi-ip32/crime.c @@ -19,8 +19,8 @@ #include #include -struct sgi_crime *crime; -struct sgi_mace *mace; +struct sgi_crime __iomem *crime; +struct sgi_mace __iomem *mace; EXPORT_SYMBOL_GPL(mace); diff --git a/include/asm-mips/ip32/crime.h b/include/asm-mips/ip32/crime.h --- a/include/asm-mips/ip32/crime.h +++ b/include/asm-mips/ip32/crime.h @@ -154,7 +154,7 @@ struct sgi_crime { #define CRIME_MEM_ERROR_ECC_REPL_MASK 0xffffffff }; -extern struct sgi_crime *crime; +extern struct sgi_crime __iomem *crime; #define CRIME_HI_MEM_BASE 0x40000000 /* this is where whole 1G of RAM is mapped */ diff --git a/include/asm-mips/ip32/mace.h b/include/asm-mips/ip32/mace.h --- a/include/asm-mips/ip32/mace.h +++ b/include/asm-mips/ip32/mace.h @@ -363,6 +363,6 @@ struct sgi_mace { char _pad6[0x80000 - sizeof(struct mace_isa)]; }; -extern struct sgi_mace *mace; +extern struct sgi_mace __iomem *mace; #endif /* __ASM_MACE_H__ */ From arnaud.giersch@free.fr Sat Nov 12 23:38:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 23:39:21 +0000 (GMT) Received: from smtp4-g19.free.fr ([212.27.42.30]:16067 "EHLO smtp4-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8136301AbVKLXgj (ORCPT ); Sat, 12 Nov 2005 23:36:39 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp4-g19.free.fr (Postfix) with ESMTP id 1E6563F5E8; Sun, 13 Nov 2005 00:38:19 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1Eb4ws-0003IV-LS; Sun, 13 Nov 2005 00:38:18 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1Eb4ws-00007G-9b; Sun, 13 Nov 2005 00:38:18 +0100 To: ralf@linux-mips.org Subject: [PATCH] Add const qualifier to writes##bwlq Cc: linux-mips@linux-mips.org Message-Id: From: Arnaud Giersch Date: Sun, 13 Nov 2005 00:38:18 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Add const qualifier to parameter addr of writes##bwlq. Signed-off-by: Arnaud Giersch --- io.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h --- a/include/asm-mips/io.h +++ b/include/asm-mips/io.h @@ -459,10 +459,10 @@ __BUILDIO(q, u64) #define __BUILD_MEMORY_STRING(bwlq, type) \ \ -static inline void writes##bwlq(volatile void __iomem *mem, void *addr, \ - unsigned int count) \ +static inline void writes##bwlq(volatile void __iomem *mem, \ + const void *addr, unsigned int count) \ { \ - volatile type *__addr = addr; \ + const volatile type *__addr = addr; \ \ while (count--) { \ mem_write##bwlq(*__addr, mem); \ From arnaud.giersch@free.fr Sat Nov 12 23:39:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Nov 2005 23:40:13 +0000 (GMT) Received: from smtp2-g19.free.fr ([212.27.42.28]:15489 "EHLO smtp2-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8136302AbVKLXgk (ORCPT ); Sat, 12 Nov 2005 23:36:40 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp2-g19.free.fr (Postfix) with ESMTP id CB126522F5; Sun, 13 Nov 2005 00:38:19 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1Eb4ws-0003IW-OZ; Sun, 13 Nov 2005 00:38:19 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1Eb4ws-00007O-Hl; Sun, 13 Nov 2005 00:38:18 +0100 To: ralf@linux-mips.org Subject: [PATCH] Documentation typos Cc: linux-mips@linux-mips.org Message-Id: From: Arnaud Giersch Date: Sun, 13 Nov 2005 00:38:18 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Fix documentation typos. Signed-off-by: Arnaud Giersch --- atomic.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/asm-mips/atomic.h b/include/asm-mips/atomic.h --- a/include/asm-mips/atomic.h +++ b/include/asm-mips/atomic.h @@ -231,11 +231,12 @@ static __inline__ int atomic_sub_return( } /* - * atomic_sub_if_positive - add integer to atomic variable + * atomic_sub_if_positive - conditionally subtract integer from atomic variable + * @i: integer value to subtract * @v: pointer of type atomic_t * - * Atomically test @v and decrement if it is greater than 0. - * The function returns the old value of @v minus 1. + * Atomically test @v and subtract @i if @v is greater or equal than @i. + * The function returns the old value of @v minus @i. */ static __inline__ int atomic_sub_if_positive(int i, atomic_t * v) { @@ -556,11 +557,12 @@ static __inline__ long atomic64_sub_retu } /* - * atomic64_sub_if_positive - add integer to atomic variable + * atomic64_sub_if_positive - conditionally subtract integer from atomic variable + * @i: integer value to subtract * @v: pointer of type atomic64_t * - * Atomically test @v and decrement if it is greater than 0. - * The function returns the old value of @v minus 1. + * Atomically test @v and subtract @i if @v is greater or equal than @i. + * The function returns the old value of @v minus @i. */ static __inline__ long atomic64_sub_if_positive(long i, atomic64_t * v) { From ralf@linux-mips.org Sun Nov 13 18:14:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Nov 2005 18:14:55 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:3612 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8136308AbVKMSOi (ORCPT ); Sun, 13 Nov 2005 18:14:38 +0000 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 jADIGLeL009265; Sun, 13 Nov 2005 18:16:21 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jADIGLQc009264; Sun, 13 Nov 2005 18:16:21 GMT Date: Sun, 13 Nov 2005 18:16:20 +0000 From: Ralf Baechle To: Arnaud Giersch Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Export IP32 mace symbol Message-ID: <20051113181620.GA7958@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9481 X-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: 105 Lines: 5 On Sun, Nov 13, 2005 at 12:38:18AM +0100, Arnaud Giersch wrote: All 5 patches applied. Thanks, Ralf From hjl@lucon.org Sun Nov 13 18:59:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Nov 2005 18:59:43 +0000 (GMT) Received: from smtp101.sbc.mail.mud.yahoo.com ([68.142.198.200]:31617 "HELO smtp101.sbc.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8136327AbVKMS7S (ORCPT ); Sun, 13 Nov 2005 18:59:18 +0000 Received: (qmail 82969 invoked from network); 13 Nov 2005 19:00:59 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@69.232.234.74 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 13 Nov 2005 19:00:58 -0000 Received: by lucon.org (Postfix, from userid 1000) id 6E83E64112; Sun, 13 Nov 2005 11:00:57 -0800 (PST) Date: Sun, 13 Nov 2005 11:00:57 -0800 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , Linas Vepstas Subject: The Linux binutils 2.16.91.0.4 os released Message-ID: <20051113190057.GA25711@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips Content-Length: 12062 Lines: 384 This is the beta release of binutils 2.16.91.0.4 for Linux, which is based on binutils 2005 0821 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.16.91.0.4 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 1111. 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 line number reporting (PR 990). 6. Fix DWARF 2 line number reporting regression on assembly file (PR 1000). Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fix an empty section removal related bug. 4. Fix an ia64 linker regression (PR 855). 5. Don't allow local symbol to be equated common/undefined symbols (PR 857). 6. Fix the ia64 linker to handle local dynamic symbol error reporting. 7. Make non-debugging reference to discarded section an error (PR 858). 8. Support Sparc/TLS. 9. Support rpm build with newer rpm. 10. Fix an alpha linker regression. 11. Fix the non-gcc build regression. Changes from binutils 2.15.94.0.2.2: 1. Update from binutils 2005 0408. 2. The i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location. 3. The x86_64 assembler now allows movq between a segment register and a 64bit general purpose register. 4. 20x Speed up linker for input files with >64K sections. 5. Properly report ia64 linker relaxation failures. 6. Support tuning ia64 assembler for Itanium 2 processors. 7. Linker will remove empty unused output sections. 8. Add -N to readelf to display full section names. 9. Fix the ia64 linker to support linkonce text sections without unwind sections. 10. More unwind directive checkings in the ia64 assembler. 11. Speed up linker with wildcard handling. 12. Fix readelf to properly dump .debug_ranges and .debug_loc sections. Changes from binutils 2.15.94.0.2: 1. Fix greater than 64K section support in linker. 2. Properly handle i386 and x86_64 protected symbols in linker. 3. Fix readelf for LEB128 on 64bit hosts. 4. Speed up readelf for section group process. 5. Include ia64 texinfo pages. 6. Change ia64 assembler to check hint.b for Montecito. 7. Improve relaxation failure report in ia64 linker. 8. Fix ia64 linker to allow relax backward branch in the same section. Changes from binutils 2.15.94.0.1: 1. Update from binutils 2004 1220. 2. Fix strip for TLS symbol references. Changes from binutils 2.15.92.0.2: 1. Update from binutils 2004 1121. 2. Put ia64 .ctors/.dtors sections next to small data section for Intel ia64 compiler. 3. Fix -Bdynamic/-Bstatic handling for linker script. 4. Provide more information on relocation overflow. 5. Add --sort-section to linker. 6. Support icc 8.1 unwind info in readelf. 7. Fix the infinite loop bug on bad input in the ia64 assembler. 8. Fix ia64 SECREL relocation in linker. 9. Fix a section group memory leak in readelf. Changes from binutils 2.15.91.0.2: 1. Update from binutils 2004 0927. 2. Work around a section header bug in Intel ia64 compiler. 3. Fix an unwind directive bug in the ia64 assembler. 4. Fix various PPC bugs. 5. Update ARM support. 6. Fix an x86-64 linker warning while building Linux kernel. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with linkonce section. 5. Added --add-needed/--no-add-needed options to linker. 6. Fix the SHF_LINK_ORDER support. 7. Fix the ia64 assembler for multiple sections with the same name and SHT_IA_64_UNWIND sections. 8. Fix the ia64 assembler for merge section and relaxation. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Prescott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.16.91.0.4.tar.bz2. Source code. 2. binutils-2.16.91.0.3-2.16.91.0.4.diff.bz2. Patch against the previous beta source code. 3. binutils-2.16.91.0.4-1.i386.rpm. IA-32 binary RPM for RedHat EL 3. 4. binutils-2.16.91.0.4-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3. 5. binutils-2.16.91.0.4-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3. There is no separate source rpm. You can do # rpmbuild -ta binutils-2.16.91.0.4.tar.bz2 to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 11/11/2005 From sshtylyov@ru.mvista.com Sun Nov 13 19:43:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Nov 2005 19:44:13 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:10418 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8136324AbVKMTnx (ORCPT ); Sun, 13 Nov 2005 19:43:53 +0000 Received: (qmail 23481 invoked from network); 13 Nov 2005 19:45:36 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 13 Nov 2005 19:45:36 -0000 Message-ID: <43779854.5040307@ru.mvista.com> Date: Sun, 13 Nov 2005 22:47:32 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS Development Subject: [Fwd: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 6007 Lines: 217 Hello. Thought it's worth forwarding this here... -------- Original Message -------- Subject: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14 Date: Sun, 13 Nov 2005 09:52:10 +0000 From: ppopov@infradead.org To: linux-mtd-cvs@lists.infradead.org Update of /home/cvs/mtd/drivers/mtd/nand In directory phoenix.infradead.org:/tmp/cvs-serv4485/drivers/mtd/nand Modified Files: au1550nd.c Log Message: 1. MEM_STNDCTL is write only. 2. Patch for problem with static bus controller which fails to keep CE asserted during chip ready delay on read commands. The problem was documented by Sergei Shtylylov; patch by the same author. Index: au1550nd.c =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- au1550nd.c 7 Nov 2005 11:14:30 -0000 1.13 +++ au1550nd.c 13 Nov 2005 09:52:07 -0000 1.14 @@ -14,9 +14,11 @@ #include #include #include +#include #include #include #include +#include #include /* fixme: this is ugly */ @@ -313,6 +315,141 @@ return ret; } +/** + * au1550_select_chip - control -CE line + * Forbid driving -CE manually permitting the NAND controller to do this. + * Keeping -CE asserted during the whole sector reads interferes with the + * NOR flash and PCMCIA drivers as it causes contention on the static bus. + * We only have to hold -CE low for the NAND read commands since the flash + * chip needs it to be asserted during chip not ready time but the NAND + * controller keeps it released. + * + * @mtd: MTD device structure + * @chip: chipnumber to select, -1 for deselect + */ +static void au1550_select_chip(struct mtd_info *mtd, int chip) +{ +} + +/** + * au1550_command - Send command to NAND device + * @mtd: MTD device structure + * @command: the command to be sent + * @column: the column address for this command, -1 if none + * @page_addr: the page address for this command, -1 if none + */ +static void au1550_command(struct mtd_info *mtd, unsigned command, int column, int page_addr) +{ + register struct nand_chip *this = mtd->priv; + int ce_override = 0, i; + ulong flags; + + /* Begin command latch cycle */ + this->hwcontrol(mtd, NAND_CTL_SETCLE); + /* + * Write out the command to the device. + */ + if (command == NAND_CMD_SEQIN) { + int readcmd; + + if (column >= mtd->oobblock) { + /* OOB area */ + column -= mtd->oobblock; + readcmd = NAND_CMD_READOOB; + } else if (column < 256) { + /* First 256 bytes --> READ0 */ + readcmd = NAND_CMD_READ0; + } else { + column -= 256; + readcmd = NAND_CMD_READ1; + } + this->write_byte(mtd, readcmd); + } + this->write_byte(mtd, command); + + /* Set ALE and clear CLE to start address cycle */ + this->hwcontrol(mtd, NAND_CTL_CLRCLE); + + if (column != -1 || page_addr != -1) { + this->hwcontrol(mtd, NAND_CTL_SETALE); + + /* Serially input address */ + if (column != -1) { + /* Adjust columns for 16 bit buswidth */ + if (this->options & NAND_BUSWIDTH_16) + column >>= 1; + this->write_byte(mtd, column); + } + if (page_addr != -1) { + this->write_byte(mtd, (u8)(page_addr & 0xff)); + + if (command == NAND_CMD_READ0 || + command == NAND_CMD_READ1 || + command == NAND_CMD_READOOB) { + /* + * NAND controller will release -CE after + * the last address byte is written, so we'll + * have to forcibly assert it. No interrupts + * are allowed while we do this as we don't + * want the NOR flash or PCMCIA drivers to + * steal our precious bytes of data... + */ + ce_override = 1; + local_irq_save(flags); + this->hwcontrol(mtd, NAND_CTL_SETNCE); + } + + this->write_byte(mtd, (u8)(page_addr >> 8)); + + /* One more address cycle for devices > 32MiB */ + if (this->chipsize > (32 << 20)) + this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f)); + } + /* Latch in address */ + this->hwcontrol(mtd, NAND_CTL_CLRALE); + } + + /* + * Program and erase have their own busy handlers. + * Status and sequential in need no delay. + */ + switch (command) { + + case NAND_CMD_PAGEPROG: + case NAND_CMD_ERASE1: + case NAND_CMD_ERASE2: + case NAND_CMD_SEQIN: + case NAND_CMD_STATUS: + return; + + case NAND_CMD_RESET: + break; + + case NAND_CMD_READ0: + case NAND_CMD_READ1: + case NAND_CMD_READOOB: + /* Check if we're really driving -CE low (just in case) */ + if (unlikely(!ce_override)) + break; + + /* Apply a short delay always to ensure that we do wait tWB. */ + ndelay(100); + /* Wait for a chip to become ready... */ + for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i) + udelay(1); + + /* Release -CE and re-enable interrupts. */ + this->hwcontrol(mtd, NAND_CTL_CLRNCE); + local_irq_restore(flags); + return; + } + /* Apply this short delay always to ensure that we do wait tWB. */ + ndelay(100); + + while(!this->dev_ready(mtd)); +} + + /* * Main initialization routine */ @@ -342,12 +479,8 @@ /* Link the private data with the MTD structure */ au1550_mtd->priv = this; - - /* disable interrupts */ - au_writel(au_readl(MEM_STNDCTL) & ~(1<<8), MEM_STNDCTL); - - /* disable NAND boot */ - au_writel(au_readl(MEM_STNDCTL) & ~(1<<0), MEM_STNDCTL); + /* MEM_STNDCTL: disable ints, disable nand boot */ + au_writel(0, MEM_STNDCTL); #ifdef CONFIG_MIPS_PB1550 /* set gpio206 high */ @@ -437,6 +570,9 @@ /* Set address of hardware control function */ this->hwcontrol = au1550_hwcontrol; this->dev_ready = au1550_device_ready; + this->select_chip = au1550_select_chip; + this->cmdfunc = au1550_command; + /* 30 us command delay time */ this->chip_delay = 30; this->eccmode = NAND_ECC_SOFT; __________________________________________________________ Linux-MTD CVS commit list http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs/ From ppopov@embeddedalley.com Sun Nov 13 19:48:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Nov 2005 19:48:45 +0000 (GMT) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:57688 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8136324AbVKMTs0 (ORCPT ); Sun, 13 Nov 2005 19:48:26 +0000 Received: (qmail 60682 invoked from network); 13 Nov 2005 19:50:09 -0000 Received: from unknown (HELO ?192.168.1.110?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 13 Nov 2005 19:50:08 -0000 Subject: Re: [Fwd: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14] From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Sergei Shtylylov Cc: Linux MIPS Development In-Reply-To: <43779854.5040307@ru.mvista.com> References: <43779854.5040307@ru.mvista.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Sun, 13 Nov 2005 11:49:59 -0800 Message-Id: <1131911400.11644.84.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9484 X-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: 6613 Lines: 225 On Sun, 2005-11-13 at 22:47 +0300, Sergei Shtylylov wrote: > Hello. > > Thought it's worth forwarding this here... Just FYI, the patch is in the mtd tree only right now. It will get to linux-mips when Ralf does a pull. Pete > -------- Original Message -------- > Subject: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14 > Date: Sun, 13 Nov 2005 09:52:10 +0000 > From: ppopov@infradead.org > To: linux-mtd-cvs@lists.infradead.org > > Update of /home/cvs/mtd/drivers/mtd/nand > In directory phoenix.infradead.org:/tmp/cvs-serv4485/drivers/mtd/nand > > Modified Files: > au1550nd.c > Log Message: > 1. MEM_STNDCTL is write only. > 2. Patch for problem with static bus controller which fails to keep > CE asserted during chip ready delay on read commands. The problem was > documented by Sergei Shtylylov; patch by the same author. > > > Index: au1550nd.c > =================================================================== > RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -r1.13 -r1.14 > --- au1550nd.c 7 Nov 2005 11:14:30 -0000 1.13 > +++ au1550nd.c 13 Nov 2005 09:52:07 -0000 1.14 > @@ -14,9 +14,11 @@ > #include > #include > #include > +#include > #include > #include > #include > +#include > #include > > /* fixme: this is ugly */ > @@ -313,6 +315,141 @@ > return ret; > } > > +/** > + * au1550_select_chip - control -CE line > + * Forbid driving -CE manually permitting the NAND controller to do this. > + * Keeping -CE asserted during the whole sector reads interferes with the > + * NOR flash and PCMCIA drivers as it causes contention on the static bus. > + * We only have to hold -CE low for the NAND read commands since the flash > + * chip needs it to be asserted during chip not ready time but the NAND > + * controller keeps it released. > + * > + * @mtd: MTD device structure > + * @chip: chipnumber to select, -1 for deselect > + */ > +static void au1550_select_chip(struct mtd_info *mtd, int chip) > +{ > +} > + > +/** > + * au1550_command - Send command to NAND device > + * @mtd: MTD device structure > + * @command: the command to be sent > + * @column: the column address for this command, -1 if none > + * @page_addr: the page address for this command, -1 if none > + */ > +static void au1550_command(struct mtd_info *mtd, unsigned command, int > column, int page_addr) > +{ > + register struct nand_chip *this = mtd->priv; > + int ce_override = 0, i; > + ulong flags; > + > + /* Begin command latch cycle */ > + this->hwcontrol(mtd, NAND_CTL_SETCLE); > + /* > + * Write out the command to the device. > + */ > + if (command == NAND_CMD_SEQIN) { > + int readcmd; > + > + if (column >= mtd->oobblock) { > + /* OOB area */ > + column -= mtd->oobblock; > + readcmd = NAND_CMD_READOOB; > + } else if (column < 256) { > + /* First 256 bytes --> READ0 */ > + readcmd = NAND_CMD_READ0; > + } else { > + column -= 256; > + readcmd = NAND_CMD_READ1; > + } > + this->write_byte(mtd, readcmd); > + } > + this->write_byte(mtd, command); > + > + /* Set ALE and clear CLE to start address cycle */ > + this->hwcontrol(mtd, NAND_CTL_CLRCLE); > + > + if (column != -1 || page_addr != -1) { > + this->hwcontrol(mtd, NAND_CTL_SETALE); > + > + /* Serially input address */ > + if (column != -1) { > + /* Adjust columns for 16 bit buswidth */ > + if (this->options & NAND_BUSWIDTH_16) > + column >>= 1; > + this->write_byte(mtd, column); > + } > + if (page_addr != -1) { > + this->write_byte(mtd, (u8)(page_addr & 0xff)); > + > + if (command == NAND_CMD_READ0 || > + command == NAND_CMD_READ1 || > + command == NAND_CMD_READOOB) { > + /* > + * NAND controller will release -CE after > + * the last address byte is written, so we'll > + * have to forcibly assert it. No interrupts > + * are allowed while we do this as we don't > + * want the NOR flash or PCMCIA drivers to > + * steal our precious bytes of data... > + */ > + ce_override = 1; > + local_irq_save(flags); > + this->hwcontrol(mtd, NAND_CTL_SETNCE); > + } > + > + this->write_byte(mtd, (u8)(page_addr >> 8)); > + > + /* One more address cycle for devices > 32MiB */ > + if (this->chipsize > (32 << 20)) > + this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f)); > + } > + /* Latch in address */ > + this->hwcontrol(mtd, NAND_CTL_CLRALE); > + } > + > + /* > + * Program and erase have their own busy handlers. > + * Status and sequential in need no delay. > + */ > + switch (command) { > + > + case NAND_CMD_PAGEPROG: > + case NAND_CMD_ERASE1: > + case NAND_CMD_ERASE2: > + case NAND_CMD_SEQIN: > + case NAND_CMD_STATUS: > + return; > + > + case NAND_CMD_RESET: > + break; > + > + case NAND_CMD_READ0: > + case NAND_CMD_READ1: > + case NAND_CMD_READOOB: > + /* Check if we're really driving -CE low (just in case) */ > + if (unlikely(!ce_override)) > + break; > + > + /* Apply a short delay always to ensure that we do wait tWB. */ > + ndelay(100); > + /* Wait for a chip to become ready... */ > + for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i) > + udelay(1); > + > + /* Release -CE and re-enable interrupts. */ > + this->hwcontrol(mtd, NAND_CTL_CLRNCE); > + local_irq_restore(flags); > + return; > + } > + /* Apply this short delay always to ensure that we do wait tWB. */ > + ndelay(100); > + > + while(!this->dev_ready(mtd)); > +} > + > + > /* > * Main initialization routine > */ > @@ -342,12 +479,8 @@ > /* Link the private data with the MTD structure */ > au1550_mtd->priv = this; > > - > - /* disable interrupts */ > - au_writel(au_readl(MEM_STNDCTL) & ~(1<<8), MEM_STNDCTL); > - > - /* disable NAND boot */ > - au_writel(au_readl(MEM_STNDCTL) & ~(1<<0), MEM_STNDCTL); > + /* MEM_STNDCTL: disable ints, disable nand boot */ > + au_writel(0, MEM_STNDCTL); > > #ifdef CONFIG_MIPS_PB1550 > /* set gpio206 high */ > @@ -437,6 +570,9 @@ > /* Set address of hardware control function */ > this->hwcontrol = au1550_hwcontrol; > this->dev_ready = au1550_device_ready; > + this->select_chip = au1550_select_chip; > + this->cmdfunc = au1550_command; > + > /* 30 us command delay time */ > this->chip_delay = 30; > this->eccmode = NAND_ECC_SOFT; > > > __________________________________________________________ > Linux-MTD CVS commit list > http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs/ > > > From sshtylyov@ru.mvista.com Sun Nov 13 19:51:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Nov 2005 19:51:41 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:21170 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8136329AbVKMTvY (ORCPT ); Sun, 13 Nov 2005 19:51:24 +0000 Received: (qmail 23707 invoked from network); 13 Nov 2005 19:53:12 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 13 Nov 2005 19:53:12 -0000 Message-ID: <43779A1C.3030505@ru.mvista.com> Date: Sun, 13 Nov 2005 22:55:08 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS Development CC: ppopov@embeddedalley.com Subject: Re: [Fwd: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14] References: <43779854.5040307@ru.mvista.com> <1131911400.11644.84.camel@localhost.localdomain> In-Reply-To: <1131911400.11644.84.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 336 Lines: 17 Hello. Pete Popov wrote: > On Sun, 2005-11-13 at 22:47 +0300, Sergei Shtylylov wrote: > >> >> Thought it's worth forwarding this here... > > > Just FYI, the patch is in the mtd tree only right now. It will get to > linux-mips when Ralf does a pull. So, now Ralf knows that it's worth doing a pull. :-) > Pete WBR, Sergei From dom@kilimandjaro.dyndns.org Mon Nov 14 08:27:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 08:27:59 +0000 (GMT) Received: from kilimandjaro.dyndns.org ([212.85.147.17]:13069 "EHLO kilimandjaro.dyndns.org") by ftp.linux-mips.org with ESMTP id S8133583AbVKNI1k (ORCPT ); Mon, 14 Nov 2005 08:27:40 +0000 Received: by kilimandjaro.dyndns.org (Postfix, from userid 500) id A990EBE861; Mon, 14 Nov 2005 09:29:25 +0100 (CET) Received: from localhost ([127.0.0.1]) by saperlipopette with esmtp (Exim 4.50) id 1EbZiu-00018K-Va; Mon, 14 Nov 2005 09:29:57 +0100 Message-ID: <43784B04.2090507@kilimandjaro.dyndns.org> Date: Mon, 14 Nov 2005 09:29:56 +0100 From: Dominique Quatravaux User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: fr, en MIME-Version: 1.0 To: Ralf Baechle Cc: Arnaud Giersch , linux-mips@linux-mips.org Subject: Re: [PATCH] Export IP32 mace symbol References: <20051113181620.GA7958@linux-mips.org> In-Reply-To: <20051113181620.GA7958@linux-mips.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@kilimandjaro.dyndns.org Precedence: bulk X-list: linux-mips Content-Length: 289 Lines: 15 Ralf Baechle a écrit : >All 5 patches applied. > > So it looks like crime.c pays, after all? M. Ralf with the mace symbol, in the code depot? :-) -- << Tout n'y est pas parfait, mais on y honore certainement les jardiniers >> Dominique Quatravaux From ralf@linux-mips.org Mon Nov 14 11:44:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 11:44:46 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:50701 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133590AbVKNLo2 (ORCPT ); Mon, 14 Nov 2005 11:44:28 +0000 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 jAEBkGRX012483 for ; Mon, 14 Nov 2005 11:46:16 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAEBkGxK012466 for linux-mips@linux-mips.org; Mon, 14 Nov 2005 11:46:16 GMT Date: Mon, 14 Nov 2005 11:46:15 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: JMR3927 Message-ID: <20051114114615.GA6186@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9487 X-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: 159 Lines: 4 Does anybody still care about the JMR3927 board? The board code is pretty badly broken. It's also currently the only user of the TX3927 in the tree. Ralf From ralf@linux-mips.org Mon Nov 14 16:01:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 16:01:46 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:30986 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133595AbVKNQB2 (ORCPT ); Mon, 14 Nov 2005 16:01:28 +0000 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 jAEG3EZ9005249; Mon, 14 Nov 2005 16:03:14 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAEG3D2r005247; Mon, 14 Nov 2005 16:03:13 GMT Date: Mon, 14 Nov 2005 16:03:13 +0000 From: Ralf Baechle To: Dominique Quatravaux Cc: Arnaud Giersch , linux-mips@linux-mips.org Subject: Re: [PATCH] Export IP32 mace symbol Message-ID: <20051114160313.GJ2793@linux-mips.org> References: <20051113181620.GA7958@linux-mips.org> <43784B04.2090507@kilimandjaro.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43784B04.2090507@kilimandjaro.dyndns.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9488 X-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: 297 Lines: 14 On Mon, Nov 14, 2005 at 09:29:56AM +0100, Dominique Quatravaux wrote: > Ralf Baechle a écrit : > > >All 5 patches applied. > > > > > So it looks like crime.c pays, after all? > > M. Ralf with the mace symbol, in the code depot? :-) Reminds me of Batman his opponent, the pinguin ;-) Ralf From anemo@mba.ocn.ne.jp Mon Nov 14 16:16:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 16:16:49 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:9455 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133595AbVKNQQ0 (ORCPT ); Mon, 14 Nov 2005 16:16:26 +0000 Received: from localhost (p7025-ipad206funabasi.chiba.ocn.ne.jp [222.145.81.25]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C3751A5E1; Tue, 15 Nov 2005 01:18:14 +0900 (JST) Date: Tue, 15 Nov 2005 01:17:21 +0900 (JST) Message-Id: <20051115.011721.25910359.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] rewrite get_wchan and its helper functions From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9489 X-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: 7145 Lines: 259 Implement get_wchan and frame_info_init using kallsyms_lookup. This fixes problem with static sched/lock functions and mfinfo[] maintenance issue. If CONFIG_KALLSYMS disabled, get_wchan just returns thread_saved_pc value. Also unwind stackframe based on "addiu sp,-imm" analysis instead of frame pointer. This fixes problem with functions compiled without -fomit-frame-pointer. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index dd72577..dafd661 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -273,46 +274,19 @@ long kernel_thread(int (*fn)(void *), vo static struct mips_frame_info { void *func; - int omit_fp; /* compiled without fno-omit-frame-pointer */ - int frame_offset; + unsigned long func_size; + int frame_size; 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 }, -}; +} *schedule_frame, mfinfo[64]; +static int mfinfo_num; -static int mips_frame_info_initialized; static int __init get_frame_info(struct mips_frame_info *info) { 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_size = 0; for (i = 0; i < 128; i++, ip++) { /* if jal, jalr, jr, stop. */ if (ip->j_format.opcode == jal_op || @@ -321,6 +295,23 @@ static int __init get_frame_info(struct ip->r_format.func == jr_op))) break; + if (info->func_size && i >= info->func_size / 4) + break; + if ( +#ifdef CONFIG_32BIT + ip->i_format.opcode == addiu_op && +#endif +#ifdef CONFIG_64BIT + ip->i_format.opcode == daddiu_op && +#endif + ip->i_format.rs == 29 && + ip->i_format.rt == 29) { + /* addiu/daddiu sp,sp,-imm */ + if (info->frame_size) + continue; + info->frame_size = - ip->i_format.simmediate; + } + if ( #ifdef CONFIG_32BIT ip->i_format.opcode == sw_op && @@ -328,31 +319,20 @@ static int __init get_frame_info(struct #ifdef CONFIG_64BIT ip->i_format.opcode == sd_op && #endif - ip->i_format.rs == 29) - { + ip->i_format.rs == 29 && + ip->i_format.rt == 31) { /* sw / sd $ra, offset($sp) */ - if (ip->i_format.rt == 31) { - if (info->pc_offset != -1) - continue; - info->pc_offset = - ip->i_format.simmediate / sizeof(long); - } - /* sw / sd $s8, offset($sp) */ - if (ip->i_format.rt == 30) { -//#if 0 /* gcc 3.4 does aggressive optimization... */ - if (info->frame_offset != -1) - continue; -//#endif - info->frame_offset = - ip->i_format.simmediate / sizeof(long); - } + if (info->pc_offset != -1) + continue; + info->pc_offset = + ip->i_format.simmediate / sizeof(long); } } - if (info->pc_offset == -1 || info->frame_offset == -1) { - printk("Can't analyze prologue code at %p\n", func); + if (info->pc_offset == -1 || info->frame_size == 0) { + if (func == schedule) + printk("Can't analyze prologue code at %p\n", func); info->pc_offset = -1; - info->frame_offset = -1; - return -1; + info->frame_size = 0; } return 0; @@ -360,25 +340,36 @@ static int __init get_frame_info(struct 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; + int i; +#ifdef CONFIG_KALLSYMS + char *modname; + char namebuf[KSYM_NAME_LEN + 1]; + unsigned long start, size, ofs; + extern char __sched_text_start[], __sched_text_end[]; + extern char __lock_text_start[], __lock_text_end[]; + + start = (unsigned long)__sched_text_start; + for (i = 0; i < ARRAY_SIZE(mfinfo); i++) { + if (start == (unsigned long)schedule) + schedule_frame = &mfinfo[i]; + if (!kallsyms_lookup(start, &size, &ofs, &modname, namebuf)) + break; + mfinfo[i].func = (void *)(start + ofs); + mfinfo[i].func_size = size; + start += size - ofs; + if (start >= (unsigned long)__lock_text_end) + break; + if (start == (unsigned long)__sched_text_end) + start = (unsigned long)__lock_text_start; + } +#else + mfinfo[0].func = schedule; + schedule_frame = &mfinfo[0]; +#endif + for (i = 0; i < ARRAY_SIZE(mfinfo) && mfinfo[i].func; i++) + get_frame_info(&mfinfo[i]); + + mfinfo_num = i; return 0; } @@ -395,47 +386,52 @@ unsigned long thread_saved_pc(struct tas if (t->reg31 == (unsigned long) ret_from_fork) return t->reg31; - if (schedule_frame.pc_offset < 0) + if (!schedule_frame || schedule_frame->pc_offset < 0) return 0; - return ((unsigned long *)t->reg29)[schedule_frame.pc_offset]; + 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 stack_page; - unsigned long frame, pc; + unsigned long pc; +#ifdef CONFIG_KALLSYMS + unsigned long frame; +#endif if (!p || p == current || p->state == TASK_RUNNING) return 0; stack_page = (unsigned long)p->thread_info; - if (!stack_page || !mips_frame_info_initialized) + if (!stack_page || !mfinfo_num) return 0; pc = thread_saved_pc(p); +#ifdef CONFIG_KALLSYMS if (!in_sched_functions(pc)) return pc; - frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset]; + frame = p->thread.reg29 + schedule_frame->frame_size; do { int i; if (frame < stack_page || frame > stack_page + THREAD_SIZE - 32) return 0; - for (i = ARRAY_SIZE(mfinfo) - 1; i >= 0; i--) { + for (i = mfinfo_num - 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]; + if (!mfinfo[i].frame_size) + break; + frame += mfinfo[i].frame_size; } while (in_sched_functions(pc)); +#endif return pc; } From daney@avtrex.com Mon Nov 14 22:58:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 22:58:18 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:28179 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S3466982AbVKNW6B (ORCPT ); Mon, 14 Nov 2005 22:58:01 +0000 Received: from dl2.hq2.avtrex.com (dl2.hq2.avtrex.com [127.0.0.1]) by avtrex.com (8.13.1/8.13.1) with ESMTP id jAEMxpBx006748 for ; Mon, 14 Nov 2005 14:59:51 -0800 Received: (from daney@localhost) by dl2.hq2.avtrex.com (8.13.1/8.13.1/Submit) id jAEMxnub006745; Mon, 14 Nov 2005 14:59:49 -0800 From: David Daney MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17273.5861.51238.726136@dl2.hq2.avtrex.com> Date: Mon, 14 Nov 2005 14:59:49 -0800 To: linux-mips@linux-mips.org Subject: [PATCH] Fix build in ide-dma.c X-Mailer: VM 7.19 under Emacs 21.3.1 Reply-To: ddaney@avtrex.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9490 X-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 Content-Length: 867 Lines: 28 When in_drive_list was renamed to ide_in_drive_list, several occurrences were missed. This patch allows me to build. David Daney diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c --- a/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -665,7 +665,7 @@ int __ide_dma_bad_drive (ide_drive_t *dr { struct hd_driveid *id = drive->id; - int blacklist = in_drive_list(id, drive_blacklist); + int blacklist = ide_in_drive_list(id, drive_blacklist); if (blacklist) { printk(KERN_WARNING "%s: Disabling (U)DMA for %s (blacklisted)\n", drive->name, id->model); @@ -679,7 +679,7 @@ EXPORT_SYMBOL(__ide_dma_bad_drive); int __ide_dma_good_drive (ide_drive_t *drive) { struct hd_driveid *id = drive->id; - return in_drive_list(id, drive_whitelist); + return ide_in_drive_list(id, drive_whitelist); } EXPORT_SYMBOL(__ide_dma_good_drive); From ddaney@avtrex.com Mon Nov 14 23:03:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Nov 2005 23:03:29 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:17440 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S3466982AbVKNXDM (ORCPT ); Mon, 14 Nov 2005 23:03:12 +0000 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:05:06 -0800 Message-ID: <43791822.3050600@avtrex.com> Date: Mon, 14 Nov 2005 15:05:06 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix build in ide-dma.c References: <17273.5861.51238.726136@dl2.hq2.avtrex.com> In-Reply-To: <17273.5861.51238.726136@dl2.hq2.avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2005 23:05:06.0260 (UTC) FILETIME=[DA462940:01C5E96F] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9491 X-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 Content-Length: 1024 Lines: 35 David Daney wrote: > When in_drive_list was renamed to ide_in_drive_list, several > occurrences were missed. This patch allows me to build. > > David Daney > I guess I should probably add: Signed-off-by: David Daney > > diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c > --- a/drivers/ide/ide-dma.c > +++ b/drivers/ide/ide-dma.c > @@ -665,7 +665,7 @@ int __ide_dma_bad_drive (ide_drive_t *dr > { > struct hd_driveid *id = drive->id; > > - int blacklist = in_drive_list(id, drive_blacklist); > + int blacklist = ide_in_drive_list(id, drive_blacklist); > if (blacklist) { > printk(KERN_WARNING "%s: Disabling (U)DMA for %s (blacklisted)\n", > drive->name, id->model); > @@ -679,7 +679,7 @@ EXPORT_SYMBOL(__ide_dma_bad_drive); > int __ide_dma_good_drive (ide_drive_t *drive) > { > struct hd_driveid *id = drive->id; > - return in_drive_list(id, drive_whitelist); > + return ide_in_drive_list(id, drive_whitelist); > } > > EXPORT_SYMBOL(__ide_dma_good_drive); > From swamim@sankhya.com Tue Nov 15 14:10:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 14:10:42 +0000 (GMT) Received: from [210.212.208.205] ([210.212.208.205]:3201 "EHLO pdns.sankhya.co.in") by ftp.linux-mips.org with ESMTP id S8133548AbVKOOKY (ORCPT ); Tue, 15 Nov 2005 14:10:24 +0000 Received: from sankhya.com (sankhya-external [192.168.1.2]) by pdns.sankhya.co.in (8.12.11/8.12.10) with ESMTP id jAFEAulE032644 for ; Tue, 15 Nov 2005 19:40:58 +0530 Received: from sankhya.com (localhost [127.0.0.1]) by sankhya.com (8.12.8/8.12.5) with ESMTP id jAFEmiUn014770 for ; Tue, 15 Nov 2005 20:18:44 +0530 Received: from localhost (swamim@localhost) by sankhya.com (8.12.8/8.12.5/Submit) with ESMTP id jAFEmRM8014752 for ; Tue, 15 Nov 2005 20:18:28 +0530 Date: Tue, 15 Nov 2005 20:18:26 +0530 (IST) From: M Ranga Swami Reddy Reply-To: swamim@sankhya.com To: linux-mips@linux-mips.org Subject: linux 2.6.14 (MIPS CVS) kernel build and testing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: swamim@sankhya.com Precedence: bulk X-list: linux-mips Content-Length: 218 Lines: 13 Hi All, Any one build and test the linux 2.6.14 kernel with mips malta board? Any good documentation available to build and boot the mips malta board with latest kernel sources? Thanks in advance. Regards, Swami From maillist@jg555.com Tue Nov 15 15:17:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 15:18:00 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:38100 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133540AbVKOPRn (ORCPT ); Tue, 15 Nov 2005 15:17:43 +0000 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; Tue, 15 Nov 2005 07:19:39 -0800 id 0028C449.4379FC8B.000024D6 Message-ID: <4379FBF4.1040505@jg555.com> Date: Tue, 15 Nov 2005 07:17:08 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Kumba , Linux MIPS List Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> In-Reply-To: <4372304A.9080608@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9493 X-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: 337 Lines: 12 I've isolated the problem to 2.6.13-rc3. What I've done is built every kernel from 2.6.13-rc1 till it failed. Also, Ralf, when I tried using git to pull those out of the git repo, they were missing files, had to use the cvs, not sure if you can verify it. I tried 2.6.13-rc1 and 2.6.13-rc2. -- ---- Jim Gifford maillist@jg555.com From ralf@linux-mips.org Tue Nov 15 15:22:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 15:23:08 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:44568 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133555AbVKOPWt (ORCPT ); Tue, 15 Nov 2005 15:22:49 +0000 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 jAFFOfH5023992; Tue, 15 Nov 2005 15:24:41 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAFFOc8b023991; Tue, 15 Nov 2005 15:24:38 GMT Date: Tue, 15 Nov 2005 15:24:37 +0000 From: Ralf Baechle To: Pete Popov Cc: Sergei Shtylylov , Linux MIPS Development Subject: Re: [Fwd: mtd/drivers/mtd/nand au1550nd.c,1.13,1.14] Message-ID: <20051115152437.GA15733@linux-mips.org> References: <43779854.5040307@ru.mvista.com> <1131911400.11644.84.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131911400.11644.84.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9494 X-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: 971 Lines: 25 On Sun, Nov 13, 2005 at 11:49:59AM -0800, Pete Popov wrote: > On Sun, 2005-11-13 at 22:47 +0300, Sergei Shtylylov wrote: > > Hello. > > > > Thought it's worth forwarding this here... > > Just FYI, the patch is in the mtd tree only right now. It will get to > linux-mips when Ralf does a pull. (This is less a direct comment to you posting than a general advice to people about what's going on in the git archive ...) On the master (that is 2.6) branch I'm doing that about once a day. This also means people are living dangerous if checking out the head of the master branch. Who doesn't want to participate in debugging all this mess is probably better or to checkout one of the tagged releases. Also not that Linus only change the version number in the Makefile when he does a release. That means for example until he releases 2.6.14-rc1 the Makefile will still say 2.6.14 - even though the diff may be huge, well above 150,000 lines in this case. Ralf From sshtylyov@ru.mvista.com Tue Nov 15 15:48:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 15:48:50 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:5570 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133574AbVKOPsd (ORCPT ); Tue, 15 Nov 2005 15:48:33 +0000 Received: (qmail 10043 invoked from network); 15 Nov 2005 15:50:27 -0000 Received: from unknown (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 15 Nov 2005 15:50:27 -0000 Message-ID: <437A043B.6040604@ru.mvista.com> Date: Tue, 15 Nov 2005 18:52:27 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS Development CC: Ralf Baechle Subject: Re: JMR3927 References: <20051114114615.GA6186@linux-mips.org> In-Reply-To: <20051114114615.GA6186@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 481 Lines: 19 Hello. Ralf Baechle wrote: > Does anybody still care about the JMR3927 board? At least there's no 2.6 release planned for this board by Montavista. > The board code is pretty > badly broken. It's also currently the only user of the TX3927 in the tree. I saw you were busy with TX3927 maintenance recently... Looks like this is another chance to remind you of my old patch: http://www.linux-mips.org/archives/linux-mips/2004-10/msg00300.html > Ralf WBR, Sergei From ralf@linux-mips.org Tue Nov 15 15:51:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 15:51:49 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:12813 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133563AbVKOPvc (ORCPT ); Tue, 15 Nov 2005 15:51:32 +0000 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 jAFFrPOC025333; Tue, 15 Nov 2005 15:53:26 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAFFrPb0025332; Tue, 15 Nov 2005 15:53:25 GMT Date: Tue, 15 Nov 2005 15:53:25 +0000 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix build in ide-dma.c Message-ID: <20051115155325.GC15733@linux-mips.org> References: <17273.5861.51238.726136@dl2.hq2.avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17273.5861.51238.726136@dl2.hq2.avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9496 X-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: 364 Lines: 12 On Mon, Nov 14, 2005 at 02:59:49PM -0800, David Daney wrote: > When in_drive_list was renamed to ide_in_drive_list, several > occurrences were missed. This patch allows me to build. Thanks, applied. The ide-dma stuff is part of the work on polishing the remaining drivers for merging to kernel.org. I hope I can get rid of that kind of stuff soon ... Ralf From ralf@linux-mips.org Tue Nov 15 16:08:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 16:09:08 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:58122 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133572AbVKOQIr (ORCPT ); Tue, 15 Nov 2005 16:08:47 +0000 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 jAFGAgF8026228; Tue, 15 Nov 2005 16:10:42 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAFGAgN3026227; Tue, 15 Nov 2005 16:10:42 GMT Date: Tue, 15 Nov 2005 16:10:42 +0000 From: Ralf Baechle To: Sergei Shtylylov Cc: Linux MIPS Development Subject: Re: JMR3927 Message-ID: <20051115161042.GE15733@linux-mips.org> References: <20051114114615.GA6186@linux-mips.org> <437A043B.6040604@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437A043B.6040604@ru.mvista.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9497 X-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: 681 Lines: 19 On Tue, Nov 15, 2005 at 06:52:27PM +0300, Sergei Shtylylov wrote: > >Does anybody still care about the JMR3927 board? > > At least there's no 2.6 release planned for this board by Montavista. > > > The board code is pretty > >badly broken. It's also currently the only user of the TX3927 in the > >tree. > > I saw you were busy with TX3927 maintenance recently... Looks like this > is another chance to remind you of my old patch: It's as much as I can do without a JMR3927 or other TX3927 board. For example the arch/mips/pci/fixup-jmr3927.c looks like it requires the attention that actually knows the platform. Until then it'll have to stay broken ... Ralf From imipak@yahoo.com Tue Nov 15 20:46:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 20:46:52 +0000 (GMT) Received: from web31501.mail.mud.yahoo.com ([68.142.198.130]:47807 "HELO web31501.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133604AbVKOUqe (ORCPT ); Tue, 15 Nov 2005 20:46:34 +0000 Received: (qmail 31992 invoked by uid 60001); 15 Nov 2005 20:48:28 -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=A2Zs4rDMkZHnaEMBoyosJ0Qgo+3fI5qm47IalsgD1crx4lJneyQcyHeJTOp9yo6N6k0AZLKSixatgkuO5TuIFZEP1IIfRmtlXaICl8fCwrooW10VFN2ZcjdTchw1QB0S1f2cJ0ou6Wb5jYd6V5EX0sEnR0etdVGK0x52xSmG0r4= ; Message-ID: <20051115204828.31990.qmail@web31501.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31501.mail.mud.yahoo.com via HTTP; Tue, 15 Nov 2005 12:48:28 PST Date: Tue, 15 Nov 2005 12:48:28 -0800 (PST) From: Jonathan Day Subject: Problems with Linux kernel on Broadcom SB1 To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 2273 Lines: 69 Hi, Trying to build the Linux kernel currently in the git archive on a Broadcom SB1 (specifically, the 1250 dual processor system). I've not been able to get any of the page sizes other than the 4K pages to work at all - it stops at boot, no error messages, just a straight lock-up. If this is a problem with the SB1, it might be wise to disable the changing of the page size for that processor. When enabling GDB support, I get the following compile-time error: arch/mips/sibyte/sb1250/irq.c: In function 'arch_init_irq': arch/mips/sibyte/sb1250/irq.c:385: error: 'kgdb_flag' undeclared (first use in this function) arch/mips/sibyte/sb1250/irq.c:385: error: (Each undeclared identifier is reported only once arch/mips/sibyte/sb1250/irq.c:385: error: for each function it appears in.) arch/mips/sibyte/sb1250/irq.c: In function 'sb1250_kgdb_interrupt': arch/mips/sibyte/sb1250/irq.c:423: warning: implicit declaration of function 'set_async_breakpoint' A quick inspection suggests copy-and-pasting lines 63 to 85 (inclusive) from arch/mips/bcm1480/irq.c to arch/mips/sb1250/irq.c, overwriting lines 63 to 71, as the bcm1480 lines seem to be much more up-to-date and do seem to fix the problem. The configure options allows me to enable MT on the SB1, but I'm pretty sure the SB1 does not support MT. If this is indeed the case, then someone might want to have this option disabled when the SB1 is selected. In fact, it might be good to hunt for core-specific options and have them in their own section. That way, you don't have obscenely-complex checks for every option. ipc/msg.c is giving a bunch of warnings - setbuf.qbytes, setbuf.uid, setbuf.gid and setbuf.mode may be being used uninitialized in the sys_msgctl and the sys_semctl functions. Probably nothing significant, and GCC does love to throw out errors for conditions that aren't actually possible, but it probably wouldn't hurt to see if there's a problem there. From time to time, I compile unexpectedly non-working kernels - does anyone know of a good set of options to enable to identify where kernel lockups could be occuring? Thanks, Jonathan (The weirdo with weekly SB1 problems) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From ddaney@avtrex.com Tue Nov 15 21:24:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 21:24:48 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:64013 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133613AbVKOVYb (ORCPT ); Tue, 15 Nov 2005 21:24:31 +0000 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 13:26:31 -0800 Message-ID: <437A5287.9030506@avtrex.com> Date: Tue, 15 Nov 2005 13:26:31 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: What are the criteria for adding a port to linux-mips... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2005 21:26:31.0473 (UTC) FILETIME=[3F330A10:01C5EA2B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9499 X-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 Content-Length: 304 Lines: 9 As you probably know I posted patches for my ATI Xilleon port to this list several weeks ago. I am in the process of incorporating changes based on the feedback I received. I guess my question is fairly simple: What hurdles must I overcome in order to get the port added to linux-mips? David Daney From imipak@yahoo.com Tue Nov 15 21:28:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 21:28:29 +0000 (GMT) Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]:62616 "HELO web31513.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133613AbVKOV2K (ORCPT ); Tue, 15 Nov 2005 21:28:10 +0000 Received: (qmail 79458 invoked by uid 60001); 15 Nov 2005 21:30:05 -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=4Rf9eQMRj63Ca5dzJdr1K0d7EjOe+K7n6JZT/u08TlslwJYRKbHUpZcuhmGJPy2bUk1tYlVx5eQSbYPnxCWflqC54zeCY+sXu2Efot8dHlVrHZejdkZM0Tp6s0AILgGDtgUugBMgFOZFvjrZiEvWAAkPjBvDipl36amhzL9Br3Y= ; Message-ID: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> Received: from [208.187.37.98] by web31513.mail.mud.yahoo.com via HTTP; Tue, 15 Nov 2005 13:30:05 PST Date: Tue, 15 Nov 2005 13:30:05 -0800 (PST) From: Jonathan Day Subject: Another problem with compiling Linux kernel To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imipak@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 2941 Lines: 82 Hi again, Using GCC 4.0.0 on the Broadcom SB1 MIPS64 board, the compilation crashes at the final link phase with the following errors: `.exit.text' referenced in section `.pdr.78' of arch/mips/kernel/built-in.o: defined in discarded section `.exit.text' of arch/mips/kernel/built-in.o `.exit.text' referenced in section `.pdr.37' of fs/built-in.o: defined in discarded section `.exit.text' of fs/built-in.o `.exit.text' referenced in section `.pdr.17' of crypto/built-in.o: defined in discarded section `.exit.text' of crypto/built-in.o `.exit.text' referenced in section `.pdr.17' of block/built-in.o: defined in discarded section `.exit.text' of block/built-in.o `.exit.text' referenced in section `.pdr.10' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o `.exit.data' referenced in section `.exit.text.403' of net/built-in.o: defined in discarded section `.exit.data' of net/built-in.o `.exit.data' referenced in section `.exit.text.403' of net/built-in.o: defined in discarded section `.exit.data' of net/built-in.o `.exit.data' referenced in section `.exit.text.403' of net/built-in.o: defined in discarded section `.exit.data' of net/built-in.o `.exit.data' referenced in section `.exit.text.403' of net/built-in.o: defined in discarded section `.exit.data' of net/built-in.o `.exit.text' referenced in section `.pdr.20' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o My first thought was "ah, might be because I'm using an old GCC, so I'll try something more recent and see what happens". When trying GCC 4.1.0 (snapshot from 20051017), I get the following error: In file included from include/linux/nfs_fs.h:15, from init/do_mounts.c:12: include/linux/pagemap.h: In function 'fault_in_pages_readable': include/linux/pagemap.h:237: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:237: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:237: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:237: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:243: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:243: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:243: error: read-only variable '__gu_val' used as 'asm' output include/linux/pagemap.h:243: error: read-only variable '__gu_val' used as 'asm' output make[1]: *** [init/do_mounts.o] Error 1 make: *** [init] Error 2 This one may be a compiler bug (experimental GCCs are, well, experimental!) but it makes it somewhat harder to know if the later issue is resolved by using a different toolchain. Any suggestions on how to fix either/both problems? Thanks, Jonathan Day __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From ddaney@avtrex.com Tue Nov 15 21:35:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Nov 2005 21:35:39 +0000 (GMT) Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:34078 "EHLO avtrex.com") by ftp.linux-mips.org with ESMTP id S8133603AbVKOVfW (ORCPT ); Tue, 15 Nov 2005 21:35:22 +0000 Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 13:37:21 -0800 Message-ID: <437A5511.8020806@avtrex.com> Date: Tue, 15 Nov 2005 13:37:21 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Day CC: linux-mips@linux-mips.org Subject: Re: Another problem with compiling Linux kernel References: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> In-Reply-To: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2005 21:37:21.0922 (UTC) FILETIME=[C2E5AE20:01C5EA2C] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9501 X-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 Content-Length: 1987 Lines: 58 Jonathan Day wrote: > Hi again, > > Using GCC 4.0.0 on the Broadcom SB1 MIPS64 board, the > compilation crashes at the final link phase with the > following errors: > . . > `.exit.text' referenced in section `.pdr.20' of > net/built-in.o: defined in discarded section > `.exit.text' of net/built-in.o > I know nothing about this one. > My first thought was "ah, might be because I'm using > an old GCC, so I'll try something more recent and see > what happens". When trying GCC 4.1.0 (snapshot from > 20051017), I get the following error: > > In file included from include/linux/nfs_fs.h:15, > from init/do_mounts.c:12: > include/linux/pagemap.h: In function > 'fault_in_pages_readable': > include/linux/pagemap.h:237: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:237: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:237: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:237: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:243: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:243: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:243: error: read-only variable > '__gu_val' used as 'asm' output > include/linux/pagemap.h:243: error: read-only variable > '__gu_val' used as 'asm' output > make[1]: *** [init/do_mounts.o] Error 1 > make: *** [init] Error 2 > > This one may be a compiler bug (experimental GCCs are, > well, experimental!) but it makes it somewhat harder > to know if the later issue is resolved by using a > different toolchain. > This is not a GCC bug, but a change in GCC behavior. One patch was posted here: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.61.0511022057140.3511%40trantor.stuart.netsweng.com I don't know if the change made it into the linux-mips git repository or not. From n_tbinh@yahoo.com Wed Nov 16 01:34:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 01:34:57 +0000 (GMT) Received: from web30711.mail.mud.yahoo.com ([68.142.201.249]:50309 "HELO web30711.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134014AbVKPBej (ORCPT ); Wed, 16 Nov 2005 01:34:39 +0000 Received: (qmail 74658 invoked by uid 60001); 16 Nov 2005 01:36:34 -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=lpQ3Rf9XP6iGvdwyQTkPSP6L8pwW1GhJ7NiF78SPMzGv+pArN8f8sScUJAM9e2XkFadBibgJcDDfTG9TQmf8LQCbdQHdcxQdlOkWLX3ac21J8FlI9TQJBtxZCAI1yzs5SViSnzot37eYXnDvA6rngLK+Tf9FwRhNX0c/PX1a7Vs= ; Message-ID: <20051116013634.74656.qmail@web30711.mail.mud.yahoo.com> Received: from [203.190.168.9] by web30711.mail.mud.yahoo.com via HTTP; Wed, 16 Nov 2005 01:36:34 GMT Date: Wed, 16 Nov 2005 01:36:34 +0000 (GMT) From: Nguyen Thanh Binh Subject: Calibrating delay loop... crashes To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: n_tbinh@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 617 Lines: 25 Hello all, When booting Monta Vista Linux on Memec board (Virtex-4 FX12 LC), it crashed after printing the following message: "Calibrating delay loop..." By looking at the source code, I found that in the init/main.c the problem came from the calibrate_delay function: jiffies was not incremented (jiffies was always equal to 0). Have anyone get the similar problem or any experience to fix it? Thank you. Binh Nguyen ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From kevink@mips.com Wed Nov 16 01:44:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 01:44:35 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:8416 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8134014AbVKPBoS (ORCPT ); Wed, 16 Nov 2005 01:44:18 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id jAG1k9ir009156; Tue, 15 Nov 2005 17:46:09 -0800 (PST) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id jAG1k516015689; Tue, 15 Nov 2005 17:46:08 -0800 (PST) Message-ID: <437A8FA1.8010404@mips.com> Date: Wed, 16 Nov 2005 02:47:13 +0100 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nguyen Thanh Binh CC: linux-mips@linux-mips.org Subject: Re: Calibrating delay loop... crashes References: <20051116013634.74656.qmail@web30711.mail.mud.yahoo.com> In-Reply-To: <20051116013634.74656.qmail@web30711.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Content-Length: 578 Lines: 21 Nguyen Thanh Binh wrote: > When booting Monta Vista Linux on Memec board > (Virtex-4 FX12 LC), it crashed after printing the > following message: > > "Calibrating delay loop..." > > By looking at the source code, I found that in the > init/main.c the problem came from the calibrate_delay > function: jiffies was not incremented (jiffies was > always equal to 0). > > Have anyone get the similar problem or any experience > to fix it? I take it that by "crashed", you mean it hung? If so, it sounds like you aren't getting any timer interrupts. Regards, Kevin K. From m_lachwani@yahoo.com Wed Nov 16 01:57:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 01:57:55 +0000 (GMT) Received: from web30906.mail.mud.yahoo.com ([68.142.200.159]:8071 "HELO web30906.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134014AbVKPB5h (ORCPT ); Wed, 16 Nov 2005 01:57:37 +0000 Received: (qmail 45716 invoked by uid 60001); 16 Nov 2005 01:59:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4pNIqsXN2JoDG7V0Y1gqeEp4KT9yRBIok7b6ygFkkAEyvR0IKz5kLaWo0x98qFgbsnF/OUG7a0oTncAKQ3IJlAW0O7/5DW5RmTY7JSlK5HWbhK62pwYS7JH73rUjcMZPR2WtjUzERkDARzcw2bXA90q7Y2C6bFsv1ElGp30AcZo= ; Message-ID: <20051116015932.45714.qmail@web30906.mail.mud.yahoo.com> Received: from [12.44.186.158] by web30906.mail.mud.yahoo.com via HTTP; Tue, 15 Nov 2005 17:59:32 PST Date: Tue, 15 Nov 2005 17:59:32 -0800 (PST) From: Manish Lachwani Subject: Re: Calibrating delay loop... crashes To: Nguyen Thanh Binh , linux-mips@linux-mips.org In-Reply-To: <20051116013634.74656.qmail@web30711.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: m_lachwani@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 829 Lines: 42 Its probably hung at that point since the timer interrupt never came. Thanks Manish Lachwani --- Nguyen Thanh Binh wrote: > Hello all, > > When booting Monta Vista Linux on Memec board > (Virtex-4 FX12 LC), it crashed after printing the > following message: > > "Calibrating delay loop..." > > By looking at the source code, I found that in the > init/main.c the problem came from the > calibrate_delay > function: jiffies was not incremented (jiffies was > always equal to 0). > > Have anyone get the similar problem or any > experience > to fix it? > > Thank you. > > Binh Nguyen > > > > > ___________________________________________________________ > > To help you stay safe and secure online, we've > developed the all new Yahoo! Security Centre. > http://uk.security.yahoo.com > > From n_tbinh@yahoo.com Wed Nov 16 02:08:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 02:08:48 +0000 (GMT) Received: from web30710.mail.mud.yahoo.com ([68.142.200.143]:59290 "HELO web30710.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134014AbVKPCIa (ORCPT ); Wed, 16 Nov 2005 02:08:30 +0000 Received: (qmail 90088 invoked by uid 60001); 16 Nov 2005 02:10:26 -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=uD6qIzSM/K8GePK80FTkXxVvJ6ffjqSGX26SJV+qXr2WVvn9KcqCqIT6lwoLHsT+cMuMAbhautt5jmFy564N8gGT/uYZGmek1nJqdPxuY1TG8Y/WgalyxCpWDP1IGHy0hqUJWA1SPIH1A6XIE93QpNXTLjev9R+wofRa1VzUVnE= ; Message-ID: <20051116021026.90086.qmail@web30710.mail.mud.yahoo.com> Received: from [203.190.168.9] by web30710.mail.mud.yahoo.com via HTTP; Wed, 16 Nov 2005 02:10:26 GMT Date: Wed, 16 Nov 2005 02:10:26 +0000 (GMT) From: Nguyen Thanh Binh Subject: Re: Calibrating delay loop... crashes To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org In-Reply-To: <437A8FA1.8010404@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: n_tbinh@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 1062 Lines: 43 Hi Kevin, > > When booting Monta Vista Linux on Memec board > > (Virtex-4 FX12 LC), it crashed after printing the > > following message: > > > > "Calibrating delay loop..." > > > > By looking at the source code, I found that in the > > init/main.c the problem came from the > calibrate_delay > > function: jiffies was not incremented (jiffies was > > always equal to 0). > > > > Have anyone get the similar problem or any > experience > > to fix it? > > I take it that by "crashed", you mean it hung? If > so, > it sounds like you aren't getting any timer > interrupts. You are right. Because jiffies was not incremented so the below code segment in function calibrate_delay in file init/mian.c hung: ticks = jiffies; while (ticks == jiffies) ; As I am a newbie, I did not find how to fix it. Thank you for any help. Binh Nguyen Nguyễn Thanh Bình ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From m_lachwani@yahoo.com Wed Nov 16 02:22:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 02:23:02 +0000 (GMT) Received: from web30904.mail.mud.yahoo.com ([68.142.200.157]:50527 "HELO web30904.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8134011AbVKPCWo (ORCPT ); Wed, 16 Nov 2005 02:22:44 +0000 Received: (qmail 44083 invoked by uid 60001); 16 Nov 2005 02:24:39 -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=P7vFvkPNXgY+QP5vTIfYAYmSsgMUfS8NxN1fW5Og6AGWbLW9i8P+HK2lSg42egnMZmuGtEIr3U6/Ul7JGcxz/DfUgmSGQU9HW9PPqVdV6aXjbDYQXsARwv1ieT0fJe/ve7b8qyPD0RViRa+B+t06xPf3YLKnBRzwB/tSX1XaRR0= ; Message-ID: <20051116022439.44081.qmail@web30904.mail.mud.yahoo.com> Received: from [12.44.186.158] by web30904.mail.mud.yahoo.com via HTTP; Tue, 15 Nov 2005 18:24:39 PST Date: Tue, 15 Nov 2005 18:24:39 -0800 (PST) From: Manish Lachwani Subject: Re: Calibrating delay loop... crashes To: Nguyen Thanh Binh , "Kevin D. Kissell" Cc: linux-mips@linux-mips.org In-Reply-To: <20051116021026.90086.qmail@web30710.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: m_lachwani@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 1446 Lines: 72 Hi ! There is a porting guide at: http://linux.junsun.net/porting-howto/ which is quite useful. Read the "System time and timer" section. It describes to some extent implementing timer services. Thanks Manish Lachwani --- Nguyen Thanh Binh wrote: > Hi Kevin, > > > > When booting Monta Vista Linux on Memec board > > > (Virtex-4 FX12 LC), it crashed after printing > the > > > following message: > > > > > > "Calibrating delay loop..." > > > > > > By looking at the source code, I found that in > the > > > init/main.c the problem came from the > > calibrate_delay > > > function: jiffies was not incremented (jiffies > was > > > always equal to 0). > > > > > > Have anyone get the similar problem or any > > experience > > > to fix it? > > > > I take it that by "crashed", you mean it hung? If > > so, > > it sounds like you aren't getting any timer > > interrupts. > > You are right. Because jiffies was not incremented > so > the below code segment in function calibrate_delay > in > file init/mian.c hung: > > ticks = jiffies; > while (ticks == jiffies) ; > > As I am a newbie, I did not find how to fix it. > > Thank you for any help. > > Binh Nguyen > > Nguyễn Thanh Bình > > > > ___________________________________________________________ > > How much free photo storage do you get? Store your > holiday > snaps for FREE with Yahoo! Photos > http://uk.photos.yahoo.com > > From colin@realtek.com.tw Wed Nov 16 07:58:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 07:59:00 +0000 (GMT) Received: from mf2.realtek.com.tw ([220.128.56.22]:63246 "EHLO mf2.realtek.com.tw") by ftp.linux-mips.org with ESMTP id S8134094AbVKPH6h (ORCPT ); Wed, 16 Nov 2005 07:58:37 +0000 Received: from msx.realtek.com.tw (unverified [172.21.1.77]) by mf2.realtek.com.tw (Clearswift SMTPRS 5.1.7) with ESMTP id for ; Wed, 16 Nov 2005 16:02:38 +0800 Received: from rtpdii3098 ([172.21.98.16]) by msx.realtek.com.tw (Lotus Domino Release 6.5.3) with ESMTP id 2005111616001636-969673 ; Wed, 16 Nov 2005 16:00:16 +0800 Message-ID: <006c01c5ea83$c7cec780$106215ac@realtek.com.tw> From: "colin" To: Subject: Does oProfile support 4KE now? Date: Wed, 16 Nov 2005 16:00:16 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-MIMETrack: Itemize by SMTP Server on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/11/16 =?Bog5?B?pFWkyCAwNDowMDoxNg==?=, Serialize by Router on msx/Realtek(Release 6.5.3|September 14, 2004) at 2005/11/16 =?Bog5?B?pFWkyCAwNDowMDoxNw==?=, Serialize complete at 2005/11/16 =?Bog5?B?pFWkyCAwNDowMDoxNw==?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: colin@realtek.com.tw Precedence: bulk X-list: linux-mips Content-Length: 213 Lines: 11 Hello, From the CVS of oProfile http://cvs.sourceforge.net/viewcvs.py/oprofile/oprofile/events/mips/, I donot see 4KE in it. Does this mean that we cannot use oProfile to profile 4KE right now? Regards, Colin From ths@networkno.de Wed Nov 16 11:13:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 11:13:41 +0000 (GMT) Received: from mx01.qsc.de ([213.148.129.14]:42424 "EHLO mx01.qsc.de") by ftp.linux-mips.org with ESMTP id S8133818AbVKPLNX (ORCPT ); Wed, 16 Nov 2005 11:13:23 +0000 Received: from port-195-158-167-39.dynamic.qsc.de ([195.158.167.39] helo=hattusa.textio) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1EcLG1-0007Dx-00; Wed, 16 Nov 2005 12:15:17 +0100 Received: from ths by hattusa.textio with local (Exim 4.54) id 1EcLFx-0002tl-4G; Wed, 16 Nov 2005 12:15:13 +0100 Date: Wed, 16 Nov 2005 12:15:13 +0100 To: Jonathan Day Cc: linux-mips@linux-mips.org Subject: Re: Another problem with compiling Linux kernel Message-ID: <20051116111512.GH5615@hattusa.textio> References: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> User-Agent: Mutt/1.5.11 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9508 X-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: 162 Lines: 9 Jonathan Day wrote: > Hi again, > > Using GCC 4.0.0 on the Broadcom SB1 MIPS64 board, Try 4.0.2 or 4.0.3 instead, it has some bugfixes which may help. Thiemo From macro@linux-mips.org Wed Nov 16 12:05:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 12:05:38 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:30474 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133818AbVKPMFU (ORCPT ); Wed, 16 Nov 2005 12:05:20 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 48868E1C89; Wed, 16 Nov 2005 13:07:22 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02890-04; Wed, 16 Nov 2005 13:07:22 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id ED8A6E1C6E; Wed, 16 Nov 2005 13:07:21 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jAGC7F0W028299; Wed, 16 Nov 2005 13:07:15 +0100 Date: Wed, 16 Nov 2005 12:07:24 +0000 (GMT) From: "Maciej W. Rozycki" To: Jonathan Day Cc: linux-mips@linux-mips.org Subject: Re: Problems with Linux kernel on Broadcom SB1 In-Reply-To: <20051115204828.31990.qmail@web31501.mail.mud.yahoo.com> Message-ID: References: <20051115204828.31990.qmail@web31501.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87/1176/Tue Nov 15 21:47:39 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9509 X-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: 429 Lines: 12 On Tue, 15 Nov 2005, Jonathan Day wrote: > I've not been able to get any of the page sizes other > than the 4K pages to work at all - it stops at boot, > no error messages, just a straight lock-up. If this is > a problem with the SB1, it might be wise to disable > the changing of the page size for that processor. It's known broken for any processor. The option is there for us to remember to fix it one day. ;-) Maciej From ralf@linux-mips.org Wed Nov 16 14:05:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 14:05:37 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:14354 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134047AbVKPOFT (ORCPT ); Wed, 16 Nov 2005 14:05:19 +0000 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 jAGE7Jr7010563; Wed, 16 Nov 2005 14:07:19 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGE7I7r010562; Wed, 16 Nov 2005 14:07:18 GMT Date: Wed, 16 Nov 2005 14:07:18 +0000 From: Ralf Baechle To: Manish Lachwani Cc: Nguyen Thanh Binh , "Kevin D. Kissell" , linux-mips@linux-mips.org Subject: Re: Calibrating delay loop... crashes Message-ID: <20051116140718.GD3229@linux-mips.org> References: <20051116021026.90086.qmail@web30710.mail.mud.yahoo.com> <20051116022439.44081.qmail@web30904.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051116022439.44081.qmail@web30904.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9510 X-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: 433 Lines: 15 On Tue, Nov 15, 2005 at 06:24:39PM -0800, Manish Lachwani wrote: > There is a porting guide at: > > http://linux.junsun.net/porting-howto/ > > which is quite useful. Read the "System time and > timer" section. It describes to some extent > implementing timer services. Except it being outdated, totally 2.4 centric and having been superseeded by the version that's now in the www.linux-mips.org wiki since almost a year. Ralf From ralf@linux-mips.org Wed Nov 16 14:30:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 14:30:29 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:62238 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134061AbVKPOaL (ORCPT ); Wed, 16 Nov 2005 14:30:11 +0000 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 jAGEWBmj011538; Wed, 16 Nov 2005 14:32:11 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGEWBSj011537; Wed, 16 Nov 2005 14:32:11 GMT Date: Wed, 16 Nov 2005 14:32:11 +0000 From: Ralf Baechle To: Jonathan Day Cc: linux-mips@linux-mips.org Subject: Re: Problems with Linux kernel on Broadcom SB1 Message-ID: <20051116143211.GE3229@linux-mips.org> References: <20051115204828.31990.qmail@web31501.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051115204828.31990.qmail@web31501.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9511 X-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: 422 Lines: 13 On Tue, Nov 15, 2005 at 12:48:28PM -0800, Jonathan Day wrote: > Trying to build the Linux kernel currently in the git > archive on a Broadcom SB1 (specifically, the 1250 dual > processor system). > > I've not been able to get any of the page sizes other > than the 4K pages to work at all - it stops at boot, This option is marked experimental. So you choose to experiment and you saw the pyrotechnics fly ;-) Ralf From ralf@linux-mips.org Wed Nov 16 15:16:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 15:16:18 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:37386 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134058AbVKPPQA (ORCPT ); Wed, 16 Nov 2005 15:16:00 +0000 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 jAGFHxts013294; Wed, 16 Nov 2005 15:17:59 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGFHxH1013293; Wed, 16 Nov 2005 15:17:59 GMT Date: Wed, 16 Nov 2005 15:17:59 +0000 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: What are the criteria for adding a port to linux-mips... Message-ID: <20051116151758.GF3229@linux-mips.org> References: <437A5287.9030506@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437A5287.9030506@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9512 X-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: 1422 Lines: 30 On Tue, Nov 15, 2005 at 01:26:31PM -0800, David Daney wrote: > As you probably know I posted patches for my ATI Xilleon port to this > list several weeks ago. I am in the process of incorporating changes > based on the feedback I received. > > I guess my question is fairly simple: > > What hurdles must I overcome in order to get the port added to linux-mips? I'm trying to handle this no different than Linus or the other subsystem maintainers. So, basically: - Code should comply to Documentation/CodingStyle - Code must be maintainable. - There probably will be issues raised when posting patches. Fix them ... - In general I won't consider patches for "one of" ports. (You asked a general question, so this is a general answer. Obviously this point isn't a problem for a SOC such as the Xilleon.) - A platform is worthless without drivers, so I want to see drivers in a shape where they're at least reasonably close to acceptable by the respective subsystem maintainers. - In the past it happened several times that people sent me their patches, I applied them and that's about the last I ever heared and so without no hardware, not hardware documentation and as always not enough time code starts bitrotting away. I would realliy appreciate if in the future submitters would make an attempt to invest a little work it takes to keep their submitted code alive ... Ralf From ralf@linux-mips.org Wed Nov 16 15:17:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 15:18:15 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:38673 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134058AbVKPPR5 (ORCPT ); Wed, 16 Nov 2005 15:17:57 +0000 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 jAGFJuG5013394; Wed, 16 Nov 2005 15:19:56 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGFJuYC013393; Wed, 16 Nov 2005 15:19:56 GMT Date: Wed, 16 Nov 2005 15:19:56 +0000 From: Ralf Baechle To: David Daney Cc: Jonathan Day , linux-mips@linux-mips.org Subject: Re: Another problem with compiling Linux kernel Message-ID: <20051116151956.GG3229@linux-mips.org> References: <20051115213005.79456.qmail@web31513.mail.mud.yahoo.com> <437A5511.8020806@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437A5511.8020806@avtrex.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9513 X-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: 1783 Lines: 46 On Tue, Nov 15, 2005 at 01:37:21PM -0800, David Daney wrote: > >what happens". When trying GCC 4.1.0 (snapshot from > >20051017), I get the following error: > > > >In file included from include/linux/nfs_fs.h:15, > > from init/do_mounts.c:12: > >include/linux/pagemap.h: In function > >'fault_in_pages_readable': > >include/linux/pagemap.h:237: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:237: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:237: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:237: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:243: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:243: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:243: error: read-only variable > >'__gu_val' used as 'asm' output > >include/linux/pagemap.h:243: error: read-only variable > >'__gu_val' used as 'asm' output > >make[1]: *** [init/do_mounts.o] Error 1 > >make: *** [init] Error 2 > > > >This one may be a compiler bug (experimental GCCs are, > >well, experimental!) but it makes it somewhat harder > >to know if the later issue is resolved by using a > >different toolchain. > > > > This is not a GCC bug, but a change in GCC behavior. One patch was > posted here: > > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.61.0511022057140.3511%40trantor.stuart.netsweng.com > > I don't know if the change made it into the linux-mips git repository or > not. That patch has a few shortcomings, so I didn't apply it yet. Unfortunately a proper solution turns out to be a pretty hard nut. Ralf From ralf@linux-mips.org Wed Nov 16 16:08:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 16:09:08 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:29447 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134064AbVKPQIv (ORCPT ); Wed, 16 Nov 2005 16:08:51 +0000 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 jAGGAjSD016500; Wed, 16 Nov 2005 16:10:46 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGGAWlP016496; Wed, 16 Nov 2005 16:10:32 GMT Date: Wed, 16 Nov 2005 16:10:32 +0000 From: Ralf Baechle To: colin Cc: linux-mips@linux-mips.org Subject: Re: Does oProfile support 4KE now? Message-ID: <20051116161031.GH3229@linux-mips.org> References: <006c01c5ea83$c7cec780$106215ac@realtek.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006c01c5ea83$c7cec780$106215ac@realtek.com.tw> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9514 X-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: 486 Lines: 13 On Wed, Nov 16, 2005 at 04:00:16PM +0800, colin wrote: > >From the CVS of oProfile > http://cvs.sourceforge.net/viewcvs.py/oprofile/oprofile/events/mips/, I > donot see 4KE in it. The 4K processors don't implement performance counters which are required for any serious use of Oprofile. Lacking performance counters there is always the fallback option of using the timer interrupt but of course that means you won't be able to take advantage of much of Oprofile's fancyness. Ralf From anemo@mba.ocn.ne.jp Wed Nov 16 16:17:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 16:18:15 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:28640 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8134064AbVKPQR4 (ORCPT ); Wed, 16 Nov 2005 16:17:56 +0000 Received: from localhost (p3230-ipad208funabasi.chiba.ocn.ne.jp [60.43.104.230]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CB423A131 for ; Thu, 17 Nov 2005 01:19:58 +0900 (JST) Date: Thu, 17 Nov 2005 01:19:06 +0900 (JST) Message-Id: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: cpu_idle and cpu_wait From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9515 X-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: 1541 Lines: 42 Looking at recent change in cpu_idle(), I find an another potential problem with cpu_wait (WAIT instruction). 48 ATTRIB_NORET void cpu_idle(void) 49 { 50 /* endless idle loop with no priority at all */ 51 while (1) { 52 while (!need_resched()) 53 if (cpu_wait) 54 (*cpu_wait)(); 55 preempt_enable_no_resched(); 56 schedule(); 57 preempt_disable(); 58 } 59 } If an interrupt raised on line 53 and the interrupt handler woke a sleeping thread up, the thread becomes runnable and current thread (idle thread) is marked as NEED_RESCHED. Since preemption is disabled, the interrupt handler just return to current thread (idle thread) without rescheduling. The idle thread then call cpu_wait() and execute WAIT instruction (or something similer). The CPU will stops until next interrupt. Then the idle task checks need_resched() and finally calls schedule(). Therefore, wakeup-resume latency will be nearly one TICK on worst case! If this analysis was correct, how to fix this? Removing above preempt_enable_no_resched/preempt_disable pair would fix it for preemptive kernel, but no point for non-preemptive kernel. Replacing them with local_irq_enable/local_irq_disable would fix it for both kernel, but there is an question: The CPU can surely exit from the WAIT instruction by interrupt even if interrupts disabled? I know the answer is yes on TX49. Any external (or counter) interrupt SIGNAL can break the WAIT instruction. How about others? --- Atsushi Nemoto From ralf@linux-mips.org Wed Nov 16 18:40:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Nov 2005 18:40:20 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:3858 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8134075AbVKPSkB (ORCPT ); Wed, 16 Nov 2005 18:40:01 +0000 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 jAGIg2Ui022985; Wed, 16 Nov 2005 18:42:02 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAGIg1Yo022984; Wed, 16 Nov 2005 18:42:01 GMT Date: Wed, 16 Nov 2005 18:42:01 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: cpu_idle and cpu_wait Message-ID: <20051116184201.GJ3229@linux-mips.org> References: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9516 X-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: 1654 Lines: 46 On Thu, Nov 17, 2005 at 01:19:06AM +0900, Atsushi Nemoto wrote: > Looking at recent change in cpu_idle(), I find an another potential > problem with cpu_wait (WAIT instruction). > > 48 ATTRIB_NORET void cpu_idle(void) > 49 { > 50 /* endless idle loop with no priority at all */ > 51 while (1) { > 52 while (!need_resched()) > 53 if (cpu_wait) > 54 (*cpu_wait)(); > 55 preempt_enable_no_resched(); > 56 schedule(); > 57 preempt_disable(); > 58 } > 59 } > > If an interrupt raised on line 53 and the interrupt handler woke a > sleeping thread up, the thread becomes runnable and current thread > (idle thread) is marked as NEED_RESCHED. > > Since preemption is disabled, the interrupt handler just return to > current thread (idle thread) without rescheduling. The idle thread > then call cpu_wait() and execute WAIT instruction (or something > similer). The CPU will stops until next interrupt. Then the idle > task checks need_resched() and finally calls schedule(). Therefore, > wakeup-resume latency will be nearly one TICK on worst case! Pleassure. > If this analysis was correct, how to fix this? > > Removing above preempt_enable_no_resched/preempt_disable pair would > fix it for preemptive kernel, but no point for non-preemptive kernel. > Replacing them with local_irq_enable/local_irq_disable would fix it > for both kernel, but there is an question: Somebody sneaking those lines into kernel.org ... > The CPU can surely exit from the WAIT instruction by interrupt > even if interrupts disabled? That's implementation dependent behaviour, unfortunately. Ralf From anemo@mba.ocn.ne.jp Thu Nov 17 02:18:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Nov 2005 02:18:52 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:54797 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8134110AbVKQCSe (ORCPT ); Thu, 17 Nov 2005 02:18:34 +0000 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; 17 Nov 2005 02:21:50 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 9A9AC20044; Thu, 17 Nov 2005 11:21:45 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 8F3951F4C5; Thu, 17 Nov 2005 11:21:45 +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 jAH2LjhO047110; Thu, 17 Nov 2005 11:21:45 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 17 Nov 2005 11:21:45 +0900 (JST) Message-Id: <20051117.112144.108306652.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: cpu_idle and cpu_wait From: Atsushi Nemoto In-Reply-To: <20051116184201.GJ3229@linux-mips.org> References: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> <20051116184201.GJ3229@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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9517 X-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: 605 Lines: 16 >>>>> On Wed, 16 Nov 2005 18:42:01 +0000, Ralf Baechle said: >> The CPU can surely exit from the WAIT instruction by interrupt even >> if interrupts disabled? ralf> That's implementation dependent behaviour, unfortunately. I checked some MIPS32/MIPS64 datasheets and found that's really inplementation-dependent. The answer is YES on (perhaps) all MIPS4K? processors but NO on 20Kc, 24K ... And I checked x86 implemetation and found that HLT or MWAIT instruction also must be used with interrupts enabled. So IIUC it seems x86 have same latency problem too. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Nov 17 07:05:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Nov 2005 07:05:40 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:63760 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133414AbVKQHFV (ORCPT ); Thu, 17 Nov 2005 07:05:21 +0000 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; 17 Nov 2005 07:08:38 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 2EA0B1FDED; Thu, 17 Nov 2005 16:08:34 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id BCBED1F4B6; Thu, 17 Nov 2005 16:08:33 +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 jAH78XhO048194; Thu, 17 Nov 2005 16:08:33 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 17 Nov 2005 16:08:33 +0900 (JST) Message-Id: <20051117.160833.130850703.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: cpu_idle and cpu_wait From: Atsushi Nemoto In-Reply-To: <20051117.112144.108306652.nemoto@toshiba-tops.co.jp> References: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> <20051116184201.GJ3229@linux-mips.org> <20051117.112144.108306652.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9518 X-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: 518 Lines: 12 >>>>> On Thu, 17 Nov 2005 11:21:45 +0900 (JST), Atsushi Nemoto said: anemo> And I checked x86 implemetation and found that HLT or MWAIT anemo> instruction also must be used with interrupts enabled. So IIUC anemo> it seems x86 have same latency problem too. No, I was wrong. MWAIT (and MONITOR) instruction provides something like "test and wait" mechanism. mwait_idle() is using them for thread_flag, so there is no latency problem on processors which have MWAIT/MONITOR. --- Atsushi Nemoto From maillist@jg555.com Thu Nov 17 22:55:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Nov 2005 22:56:04 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:44673 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8134172AbVKQWzn (ORCPT ); Thu, 17 Nov 2005 22:55:43 +0000 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; Thu, 17 Nov 2005 14:57:54 -0800 id 002B8A5B.437D0AF2.000047F4 Message-ID: <437D0AE2.9040706@jg555.com> Date: Thu, 17 Nov 2005 14:57:38 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Kumba , Linux MIPS List , ralf@linux-mips.org, Peter Horton Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> <4379FBF4.1040505@jg555.com> In-Reply-To: <4379FBF4.1040505@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9519 X-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: 4569 Lines: 184 Ok, Isolated the problem down to one file, will see if this patch will fix the issue with 2.6.14, the patch is the a diff of a file from 2.6.13-rc2 and 2.6.13-rc3 which introduced the issue. Here is a link to the patch http://ftp.jg555.com/cobalt/culprit Will test 2.6.14 with this patch a report back. diff -Naur linux-mips-2.6.13-rc3/arch/mips/kernel/cpu-probe.c testbed/arch/mips/kernel/cpu-probe.c --- linux-mips-2.6.13-rc3/arch/mips/kernel/cpu-probe.c 2005-07-27 14:48:12.000000000 -0700 +++ testbed/arch/mips/kernel/cpu-probe.c 2005-11-17 14:18:56.000000000 -0800 @@ -71,27 +71,11 @@ : : "r" (au1k_wait)); } -static int __initdata nowait = 0; - -int __init wait_disable(char *s) -{ - nowait = 1; - - return 1; -} - -__setup("nowait", wait_disable); - static inline void check_wait(void) { struct cpuinfo_mips *c = ¤t_cpu_data; printk("Checking for 'wait' instruction... "); - if (nowait) { - printk (" disabled.\n"); - return; - } - switch (c->cputype) { case CPU_R3081: case CPU_R3081E: @@ -121,7 +105,6 @@ case CPU_24K: case CPU_25KF: case CPU_34K: - case CPU_PR4450: cpu_wait = r4k_wait; printk(" available.\n"); break; @@ -147,6 +130,58 @@ check_wait(); } +#ifdef CONFIG_64BIT + +/* + * On RM5230/5231 all accesses to XKPHYS by LL(D) are forced + * to be uncached, bits 61-59 of the address are ignored. + * + * Apparently fixed on RM5230A/5231A. + */ +static inline int check_lld(void) +{ + unsigned long flags, value, match, phys, *addr; + + printk("Checking for lld bug... "); + + /* hope the stack is in the low 512MB */ + phys = CPHYSADDR((unsigned long) &value); + + /* write value to memory */ + value = 0xfedcba9876543210; + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_UNCACHED, phys); + *addr = value; + + /* stop spurious flushes */ + local_irq_save(flags); + + /* flip cached value */ + value = ~value; + + /* read value, supposedly from cache */ + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_NONCOHERENT, phys); + asm volatile("lld %0, %1" : "=r" (match) : "m" (*addr)); + + local_irq_restore(flags); + + match ^= value; + + switch ((long) match) { + case 0: + printk("no.\n"); + break; + case -1: + printk("yes.\n"); + break; + default: + printk("yikes yes! (%lx/%lx@%p)\nPlease report to .", value, match, &value); + } + + return !match; +} + +#endif + /* * Probe whether cpu has config register by trying to play with * alternate cache bit and see whether it matters. @@ -283,8 +318,7 @@ case PRID_IMP_R4600: c->cputype = CPU_R4600; c->isa_level = MIPS_CPU_ISA_III; - c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_LLSC; + c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC; c->tlbsize = 48; break; #if 0 @@ -364,7 +398,11 @@ c->cputype = CPU_NEVADA; c->isa_level = MIPS_CPU_ISA_IV; c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_DIVEC | MIPS_CPU_LLSC; + MIPS_CPU_DIVEC; +#ifdef CONFIG_64BIT + if (check_lld()) +#endif + c->options |= MIPS_CPU_LLSC; c->tlbsize = 48; break; case PRID_IMP_R6000: @@ -509,12 +547,6 @@ c->ases |= MIPS_ASE_SMARTMIPS; if (config3 & MIPS_CONF3_DSP) c->ases |= MIPS_ASE_DSP; - if (config3 & MIPS_CONF3_VINT) - c->ases |= MIPS_CPU_VINT; - if (config3 & MIPS_CONF3_VEIC) - c->ases |= MIPS_CPU_VEIC; - if (config3 & MIPS_CONF3_MT) - c->ases |= MIPS_CPU_MIPSMT; return config3 & MIPS_CONF_M; } @@ -632,21 +664,6 @@ } } -static inline void cpu_probe_philips(struct cpuinfo_mips *c) -{ - decode_configs(c); - switch (c->processor_id & 0xff00) { - case PRID_IMP_PR4450: - c->cputype = CPU_PR4450; - c->isa_level = MIPS_CPU_ISA_M32; - break; - default: - panic("Unknown Philips Core!"); /* REVISIT: die? */ - break; - } -} - - __init void cpu_probe(void) { struct cpuinfo_mips *c = ¤t_cpu_data; @@ -672,9 +689,6 @@ case PRID_COMP_SANDCRAFT: cpu_probe_sandcraft(c); break; - case PRID_COMP_PHILIPS: - cpu_probe_philips(c); - break; default: c->cputype = CPU_UNKNOWN; } -- ---- Jim Gifford maillist@jg555.com From maillist@jg555.com Fri Nov 18 01:19:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Nov 2005 01:19:50 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:1159 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8134181AbVKRBTc (ORCPT ); Fri, 18 Nov 2005 01:19:32 +0000 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; Thu, 17 Nov 2005 17:21:44 -0800 id 002B8E03.437D2CA8.000036F7 Message-ID: <437D2C97.8070804@jg555.com> Date: Thu, 17 Nov 2005 17:21:27 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Kumba , Linux MIPS List , ralf@linux-mips.org, Peter Horton Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> <4379FBF4.1040505@jg555.com> <437D0AE2.9040706@jg555.com> In-Reply-To: <437D0AE2.9040706@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9520 X-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: 2843 Lines: 112 Got a fix for 2.6.14, http://ftp.jg555.com/cobalt/fix-2.6.14. Ralf, I know this is probably not the fix you would like to see, any suggestions. diff -Naur linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c --- linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c 2005-11-17 11:42:19.000000000 -0800 +++ linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c 2005-11-17 15:00:11.000000000 -0800 @@ -121,7 +105,6 @@ case CPU_24K: case CPU_25KF: case CPU_34K: - case CPU_PR4450: cpu_wait = r4k_wait; printk(" available.\n"); break; @@ -147,6 +130,58 @@ check_wait(); } +#ifdef CONFIG_64BIT + +/* + * On RM5230/5231 all accesses to XKPHYS by LL(D) are forced + * to be uncached, bits 61-59 of the address are ignored. + * + * Apparently fixed on RM5230A/5231A. + */ +static inline int check_lld(void) +{ + unsigned long flags, value, match, phys, *addr; + + printk("Checking for lld bug... "); + + /* hope the stack is in the low 512MB */ + phys = CPHYSADDR((unsigned long) &value); + + /* write value to memory */ + value = 0xfedcba9876543210; + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_UNCACHED, phys); + *addr = value; + + /* stop spurious flushes */ + local_irq_save(flags); + + /* flip cached value */ + value = ~value; + + /* read value, supposedly from cache */ + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_NONCOHERENT, phys); + asm volatile("lld %0, %1" : "=r" (match) : "m" (*addr)); + + local_irq_restore(flags); + + match ^= value; + + switch ((long) match) { + case 0: + printk("no.\n"); + break; + case -1: + printk("yes.\n"); + break; + default: + printk("yikes yes! (%lx/%lx@%p)\nPlease report to .", value, match, &value); + } + + return !match; +} + +#endif + /* * Probe whether cpu has config register by trying to play with * alternate cache bit and see whether it matters. @@ -285,8 +320,7 @@ case PRID_IMP_R4600: c->cputype = CPU_R4600; c->isa_level = MIPS_CPU_ISA_III; - c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_LLSC; + c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_LLSC; c->tlbsize = 48; break; #if 0 @@ -366,7 +400,11 @@ c->cputype = CPU_NEVADA; c->isa_level = MIPS_CPU_ISA_IV; c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_DIVEC | MIPS_CPU_LLSC; + MIPS_CPU_DIVEC; +#ifdef CONFIG_64BIT + if (check_lld()) +#endif + c->options |= MIPS_CPU_LLSC; c->tlbsize = 48; break; case PRID_IMP_R6000: -- -- ---- Jim Gifford maillist@jg555.com From anemo@mba.ocn.ne.jp Fri Nov 18 03:19:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Nov 2005 03:19:43 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:35622 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8134185AbVKRDTY (ORCPT ); Fri, 18 Nov 2005 03:19:24 +0000 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; 18 Nov 2005 03:22:46 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 382A92005F; Fri, 18 Nov 2005 12:22:43 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 240C82005A; Fri, 18 Nov 2005 12:22: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 jAI3MghO052609; Fri, 18 Nov 2005 12:22:43 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 18 Nov 2005 12:22:42 +0900 (JST) Message-Id: <20051118.122242.07017522.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: cpu_idle and cpu_wait From: Atsushi Nemoto In-Reply-To: <20051116184201.GJ3229@linux-mips.org> References: <20051117.011906.25910026.anemo@mba.ocn.ne.jp> <20051116184201.GJ3229@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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9521 X-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: 2103 Lines: 80 >>>>> On Wed, 16 Nov 2005 18:42:01 +0000, Ralf Baechle said: >> The CPU can surely exit from the WAIT instruction by interrupt even >> if interrupts disabled? ralf> That's implementation dependent behaviour, unfortunately. Then how about this patch? By datasheets, MIPS4K?, MIPS5Kc, TX49 (and TX39 using HALT bit instead of WAIT insn) allow us entering WAIT with interrupt disabled. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index d2ae111..4bdd8c1 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -39,16 +39,33 @@ static void r3081_wait(void) static void r39xx_wait(void) { - unsigned long cfg = read_c0_conf(); - write_c0_conf(cfg | TX39_CONF_HALT); + local_irq_disable(); + if (!need_resched()) + write_c0_conf(read_c0_conf() | TX39_CONF_HALT); + local_irq_enable(); } +/* + * There is a race when WAIT instruction executed with interrupt + * enabled. + * But it is implementation-dependent wheter the pipelie restarts when + * a non-enabled interrupt is requested. + */ static void r4k_wait(void) { __asm__(".set\tmips3\n\t" "wait\n\t" ".set\tmips0"); } +static void r4k_wait_irqoff(void) +{ + local_irq_disable(); + if (!need_resched()) + __asm__(".set\tmips3\n\t" + "wait\n\t" + ".set\tmips0"); + local_irq_enable(); +} /* The Au1xxx wait is available only if using 32khz counter or * external timer source, but specifically not CP0 Counter. */ @@ -112,11 +129,6 @@ static inline void check_wait(void) case CPU_NEVADA: case CPU_RM7000: case CPU_RM9000: - case CPU_TX49XX: - case CPU_4KC: - case CPU_4KEC: - case CPU_4KSC: - case CPU_5KC: /* case CPU_20KC:*/ case CPU_24K: case CPU_25KF: @@ -125,6 +137,14 @@ static inline void check_wait(void) cpu_wait = r4k_wait; printk(" available.\n"); break; + case CPU_TX49XX: + case CPU_4KC: + case CPU_4KEC: + case CPU_4KSC: + case CPU_5KC: + cpu_wait = r4k_wait_irqoff; + printk(" available.\n"); + break; case CPU_AU1000: case CPU_AU1100: case CPU_AU1500: From ralf@linux-mips.org Fri Nov 18 17:16:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Nov 2005 17:16:56 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:53258 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133748AbVKRRQf (ORCPT ); Fri, 18 Nov 2005 17:16:35 +0000 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 jAIHH8gJ018000; Fri, 18 Nov 2005 17:17:09 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAIHH7LW017999; Fri, 18 Nov 2005 17:17:07 GMT Date: Fri, 18 Nov 2005 17:17:07 +0000 From: Ralf Baechle To: Jim Gifford Cc: Kumba , Linux MIPS List , Peter Horton Subject: Re: MIPS - 64bit woes Message-ID: <20051118171706.GD2707@linux-mips.org> References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> <4379FBF4.1040505@jg555.com> <437D0AE2.9040706@jg555.com> <437D2C97.8070804@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437D2C97.8070804@jg555.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9522 X-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: 1368 Lines: 41 On Thu, Nov 17, 2005 at 05:21:27PM -0800, Jim Gifford wrote: > Got a fix for 2.6.14, http://ftp.jg555.com/cobalt/fix-2.6.14. > > Ralf, I know this is probably not the fix you would like to see, any > suggestions. > > diff -Naur linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c > linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c > --- linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c 2005-11-17 > 11:42:19.000000000 -0800 > +++ linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c 2005-11-17 > 15:00:11.000000000 -0800 > @@ -121,7 +105,6 @@ > case CPU_24K: > case CPU_25KF: > case CPU_34K: > - case CPU_PR4450: > cpu_wait = r4k_wait; > printk(" available.\n"); > break; Ehhh? As for the remainder of your patch - the fact that this actually works made me notice that there is no cpu-features-override.h for Cobalt which means that Cobalt kernels carry a rather heavyweight generic cachecode including spinlocks and all sorts of atomic operations that will at runtime select between ll/sc and non-ll/sc variants. That's slow and I would rather suggest you get rid of that overhead by simply pretending not to have ll/sc at all on Cobalt but putting something like #ifdef CONFIG_64BIT #define cpu_has_llsc 0 #else #define cpu_has_llsc 1 #endif into the Cobalt cpu-features-override.h. Ralf From maillist@jg555.com Fri Nov 18 17:22:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Nov 2005 17:23:25 +0000 (GMT) Received: from Jg555.com ([64.30.195.78]:35466 "EHLO jg555.com") by ftp.linux-mips.org with ESMTP id S8133750AbVKRRW5 (ORCPT ); Fri, 18 Nov 2005 17:22:57 +0000 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; Fri, 18 Nov 2005 09:25:13 -0800 id 001F5613.437E0E7A.00003014 Message-ID: <437E0E68.7010008@jg555.com> Date: Fri, 18 Nov 2005 09:24:56 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Kumba , Linux MIPS List , Peter Horton Subject: Re: MIPS - 64bit woes References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> <4379FBF4.1040505@jg555.com> <437D0AE2.9040706@jg555.com> <437D2C97.8070804@jg555.com> <20051118171706.GD2707@linux-mips.org> In-Reply-To: <20051118171706.GD2707@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9523 X-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: 343 Lines: 12 I'll give it a shot and send back results and a updated patch. One more question, what is the future off the iomap.c file, I didn't include it in my patch. Could it be simply be added to arch/mips/cobalt? I can only speak for the RaQ2, but is it required for any of the other MIPS based machines? -- ---- Jim Gifford maillist@jg555.com From ralf@linux-mips.org Fri Nov 18 17:28:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Nov 2005 17:28:32 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:795 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133742AbVKRR2K (ORCPT ); Fri, 18 Nov 2005 17:28:10 +0000 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 jAIHTmAF018549; Fri, 18 Nov 2005 17:29:48 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAIHTmlv018548; Fri, 18 Nov 2005 17:29:48 GMT Date: Fri, 18 Nov 2005 17:29:48 +0000 From: Ralf Baechle To: Jim Gifford Cc: Kumba , Linux MIPS List , Peter Horton Subject: Re: MIPS - 64bit woes Message-ID: <20051118172948.GE2707@linux-mips.org> References: <436D0061.5070100@jg555.com> <4371B87A.9040101@jg555.com> <4371FB46.1000805@gentoo.org> <4372304A.9080608@jg555.com> <4379FBF4.1040505@jg555.com> <437D0AE2.9040706@jg555.com> <437D2C97.8070804@jg555.com> <20051118171706.GD2707@linux-mips.org> <437E0E68.7010008@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437E0E68.7010008@jg555.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9524 X-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: 509 Lines: 13 On Fri, Nov 18, 2005 at 09:24:56AM -0800, Jim Gifford wrote: > I'll give it a shot and send back results and a updated patch. > > One more question, what is the future off the iomap.c file, I didn't > include it in my patch. Could it be simply be added to arch/mips/cobalt? > I can only speak for the RaQ2, but is it required for any of the other > MIPS based machines? No. It's broken for machines with multiple PCI busses and I've explicitly rejected the patch which is in kernel.org before. Ralf From anemo@mba.ocn.ne.jp Sat Nov 19 17:35:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Nov 2005 17:35:32 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:44226 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133450AbVKSRfM (ORCPT ); Sat, 19 Nov 2005 17:35:12 +0000 Received: from localhost (p1084-ipad205funabasi.chiba.ocn.ne.jp [222.146.96.84]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 205F5AA9D; Sun, 20 Nov 2005 02:37:31 +0900 (JST) Date: Sun, 20 Nov 2005 02:36:41 +0900 (JST) Message-Id: <20051120.023641.41197425.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: maillist@jg555.com, kumba@gentoo.org, linux-mips@linux-mips.org, pdh@colonel-panic.org Subject: mips iomap.c (Was: Re: MIPS - 64bit woes) From: Atsushi Nemoto In-Reply-To: <20051118172948.GE2707@linux-mips.org> References: <20051118171706.GD2707@linux-mips.org> <437E0E68.7010008@jg555.com> <20051118172948.GE2707@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.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9525 X-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: 634 Lines: 17 >>>>> On Fri, 18 Nov 2005 17:29:48 +0000, Ralf Baechle said: ralf> No. It's broken for machines with multiple PCI busses and I've ralf> explicitly rejected the patch which is in kernel.org before. Could you explain a bit _how_ broken current kernel.org's arch/mips/lib/iomap.c ? Is it a single mips_io_port_base issue? I suppose it works as well as traditional way (request_region + in[bwl] for IO resource, request_mem_region + iomap + read[bwl] for MEM resource). I think it is better than generic iomap.c (except that ioremap_cacheable_cow which is not available for R3000 is used). --- Atsushi Nemoto From arnaud.giersch@free.fr Sun Nov 20 14:40:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Nov 2005 14:41:02 +0000 (GMT) Received: from smtp2-g19.free.fr ([212.27.42.28]:48007 "EHLO smtp2-g19.free.fr") by ftp.linux-mips.org with ESMTP id S8133616AbVKTOkc (ORCPT ); Sun, 20 Nov 2005 14:40:32 +0000 Received: from groumpf (str90-1-82-238-123-182.fbx.proxad.net [82.238.123.182]) by smtp2-g19.free.fr (Postfix) with ESMTP id D41684684D; Sun, 20 Nov 2005 15:42:55 +0100 (CET) Received: from jekyll.groumpf.homeip.net ([192.168.1.1] helo=jekyll) by groumpf with esmtp (Exim 4.50) id 1EdqP8-0002PH-N5; Sun, 20 Nov 2005 15:42:54 +0100 Received: from arnaud by jekyll with local (Exim 4.50) id 1EdqP8-00007T-2M; Sun, 20 Nov 2005 15:42:54 +0100 To: philb@gnu.org, tim@cyberelk.net, campbell@torque.net, andrea@suse.de Cc: linux-parport@lists.infradead.org, linux-mips@linux-mips.org Subject: [PATCH] parport: add parallel port support for SGI O2 From: Arnaud Giersch Date: Sun, 20 Nov 2005 15:42:53 +0100 Message-ID: <87zmnz4byq.fsf@groumpf.homeip.net> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arnaud.giersch@free.fr Precedence: bulk X-list: linux-mips Content-Length: 76446 Lines: 2386 Add support for the built-in parallel port on SGI O2 (a.k.a. IP32). Define a new configuration option: PARPORT_IP32. The module is named parport_ip32. Hardware support for SPP, EPP and ECP modes along with DMA support when needed are currently implemented. Signed-off-by: Arnaud Giersch --- The patch is submitted to the linux-parport maintainers; linux-mips@l-m.o is Cc'ed for information. drivers/parport/Kconfig | 9 drivers/parport/Makefile | 1 drivers/parport/parport_ip32.c | 2313 +++++++++++++++++++++++++++++++++++++++++ include/linux/parport.h | 6 4 files changed, 2329 insertions(+) diff -Naurp linux-2.6.15-rc2.old/drivers/parport/Kconfig linux-2.6.15-rc2/drivers/parport/Kconfig --- linux-2.6.15-rc2.old/drivers/parport/Kconfig 2005-11-20 04:25:03.000000000 +0100 +++ linux-2.6.15-rc2/drivers/parport/Kconfig 2005-11-20 15:04:17.000000000 +0100 @@ -90,6 +90,15 @@ config PARPORT_ARC depends on ARM && PARPORT select PARPORT_NOT_PC +config PARPORT_IP32 + tristate "SGI IP32 builtin port (EXPERIMENTAL)" + depends on SGI_IP32 && PARPORT && EXPERIMENTAL + select PARPORT_NOT_PC + help + Say Y here if you need support for the parallel port on + SGI O2 machines. This code is also available as a module (say M), + called parport_ip32. If in doubt, saying N is the safe plan. + config PARPORT_AMIGA tristate "Amiga builtin port" depends on AMIGA && PARPORT diff -Naurp linux-2.6.15-rc2.old/drivers/parport/Makefile linux-2.6.15-rc2/drivers/parport/Makefile --- linux-2.6.15-rc2.old/drivers/parport/Makefile 2005-11-20 04:25:03.000000000 +0100 +++ linux-2.6.15-rc2/drivers/parport/Makefile 2005-11-20 15:04:17.000000000 +0100 @@ -17,3 +17,4 @@ obj-$(CONFIG_PARPORT_MFC3) += parport_mf obj-$(CONFIG_PARPORT_ATARI) += parport_atari.o obj-$(CONFIG_PARPORT_SUNBPP) += parport_sunbpp.o obj-$(CONFIG_PARPORT_GSC) += parport_gsc.o +obj-$(CONFIG_PARPORT_IP32) += parport_ip32.o diff -Naurp linux-2.6.15-rc2.old/drivers/parport/parport_ip32.c linux-2.6.15-rc2/drivers/parport/parport_ip32.c --- linux-2.6.15-rc2.old/drivers/parport/parport_ip32.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.15-rc2/drivers/parport/parport_ip32.c 2005-11-20 15:09:27.000000000 +0100 @@ -0,0 +1,2313 @@ +/* Low-level parallel port routines for built-in port on SGI IP32 + * + * Author: Arnaud Giersch + * + * $Id: parport_ip32.c,v 1.63 2005/11/15 00:00:16 arnaud Exp $ + * + * Based on parport_pc.c by + * Phil Blundell, Tim Waugh, Jose Renau, David Campbell, + * Andrea Arcangeli, et al. + * + * Thanks to Ilya A. Volynets-Evenbakh for his help. + * + * Copyright (C) 2005 Arnaud Giersch. + * + * 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. + */ + +/* Current status: + * + * Basic SPP and PS2 modes are supported. + * Support for parallel port IRQ is present. + * Hardware SPP (a.k.a. compatibility), EPP, and ECP modes are + * supported. + * SPP/ECP FIFO can be driven in PIO or DMA mode. PIO mode can work with + * or without interrupt support. + * + * Hardware ECP mode is not fully implemented (ecp_read_data and + * ecp_write_addr are actually missing). + * + * To do: + * + * Fully implement ECP mode. + * EPP and ECP mode need to be tested. I currently do not own any + * peripheral supporting these extended mode, and cannot test them. + * If DMA mode works well, decide if support for PIO FIFO modes should be + * dropped. + */ + +/* The built-in parallel port on the SGI 02 workstation (a.k.a. IP32) is an + * IEEE 1284 parallel port driven by a Texas Instrument TL16PIR552PH chip[1]. + * This chip supports SPP, bidirectional, EPP and ECP modes. It has a 16 byte + * FIFO buffer and supports DMA transfers. + * + * [1] http://focus.ti.com/docs/prod/folders/print/tl16pir552.html + * + * Theoretically, we could simply use the parport_pc module. It is however + * not so simple. The parport_pc code assumes that the parallel port + * registers are port-mapped. On the O2, they are memory-mapped. + * Furthermore, each register is replicated on 256 consecutive addresses (as + * it is for the built-in serial ports on the same chip). + * + * Parts of the code were directly adapted from parport_pc. A better approach + * would certainly be to make the corresponding code arch-independent, with + * some generic functions for register access. + */ + +/*--- Some configuration defines ---------------------------------------*/ + +/* DEBUG_PARPORT_IP32 + * 0 disable debug + * 1 standard level: pr_debug1 is enabled + * 2 parport_ip32_dump_state is enabled + * >=3 verbose level: pr_debug is enabled + */ +#define DEBUG_PARPORT_IP32 0 /* 0 (disabled) for production */ + +/*----------------------------------------------------------------------*/ + +/* Setup DEBUG macros. This is done before any includes, just in case we + * activate pr_debug() with DEBUG_PARPORT_IP32 >= 3. + */ +#if DEBUG_PARPORT_IP32 == 1 +# warning DEBUG_PARPORT_IP32 == 1 +#elif DEBUG_PARPORT_IP32 == 2 +# warning DEBUG_PARPORT_IP32 == 2 +#elif DEBUG_PARPORT_IP32 >= 3 +# warning DEBUG_PARPORT_IP32 >= 3 +# if !defined(DEBUG) +# define DEBUG /* enable pr_debug() in kernel.h */ +# endif +#endif + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/*--- Global variables -------------------------------------------------*/ + +/* Verbose probing on by default for debugging. */ +#if DEBUG_PARPORT_IP32 >= 1 +# define DEFAULT_VERBOSE_PROBING 1 +#else +# define DEFAULT_VERBOSE_PROBING 0 +#endif + +/* Default prefix for printk */ +#define PPIP32 "parport_ip32: " + +/* + * These are the module parameters: + * @features: bit mask of features to enable/disable + * (all enabled by default) + * @verbose_probing: log chit-chat during initialization + */ +#define PARPORT_IP32_ENABLE_IRQ (1U << 0) +#define PARPORT_IP32_ENABLE_DMA (1U << 1) +#define PARPORT_IP32_ENABLE_SPP (1U << 2) +#define PARPORT_IP32_ENABLE_EPP (1U << 3) +#define PARPORT_IP32_ENABLE_ECP (1U << 4) +static unsigned int features = ~0U; +static int verbose_probing = DEFAULT_VERBOSE_PROBING; + +/* We do not support more than one port. */ +static struct parport *this_port = NULL; + +/* Timing constants for FIFO modes. */ +#define FIFO_NFAULT_TIMEOUT 100 /* milliseconds */ +#define FIFO_POLLING_INTERVAL 50 /* microseconds */ + +/*--- I/O register definitions -----------------------------------------*/ + +/** + * struct parport_ip32_regs - virtual addresses of parallel port registers + * @data: Data Register + * @dsr: Device Status Register + * @dcr: Device Control Register + * @eppAddr: EPP Address Register + * @eppData0: EPP Data Register 0 + * @eppData1: EPP Data Register 1 + * @eppData2: EPP Data Register 2 + * @eppData3: EPP Data Register 3 + * @ecpAFifo: ECP Address FIFO + * @fifo: General FIFO register. The same address is used for: + * - cFifo, the Parallel Port DATA FIFO + * - ecpDFifo, the ECP Data FIFO + * - tFifo, the ECP Test FIFO + * @cnfgA: Configuration Register A + * @cnfgB: Configuration Register B + * @ecr: Extended Control Register + */ +struct parport_ip32_regs { + void __iomem *data; + void __iomem *dsr; + void __iomem *dcr; + void __iomem *eppAddr; + void __iomem *eppData0; + void __iomem *eppData1; + void __iomem *eppData2; + void __iomem *eppData3; + void __iomem *ecpAFifo; + void __iomem *fifo; + void __iomem *cnfgA; + void __iomem *cnfgB; + void __iomem *ecr; +}; + +/* Device Status Register */ +#define DSR_nBUSY (1U << 7) /* PARPORT_STATUS_BUSY */ +#define DSR_nACK (1U << 6) /* PARPORT_STATUS_ACK */ +#define DSR_PERROR (1U << 5) /* PARPORT_STATUS_PAPEROUT */ +#define DSR_SELECT (1U << 4) /* PARPORT_STATUS_SELECT */ +#define DSR_nFAULT (1U << 3) /* PARPORT_STATUS_ERROR */ +#define DSR_nPRINT (1U << 2) /* specific to TL16PIR552 */ +/* #define DSR_reserved (1U << 1) */ +#define DSR_TIMEOUT (1U << 0) /* EPP timeout */ + +/* Device Control Register */ +/* #define DCR_reserved (1U << 7) | (1U << 6) */ +#define DCR_DIR (1U << 5) /* direction */ +#define DCR_IRQ (1U << 4) /* interrupt on nAck */ +#define DCR_SELECT (1U << 3) /* PARPORT_CONTROL_SELECT */ +#define DCR_nINIT (1U << 2) /* PARPORT_CONTROL_INIT */ +#define DCR_AUTOFD (1U << 1) /* PARPORT_CONTROL_AUTOFD */ +#define DCR_STROBE (1U << 0) /* PARPORT_CONTROL_STROBE */ + +/* ECP Configuration Register A */ +#define CNFGA_IRQ (1U << 7) +#define CNFGA_ID_MASK ((1U << 6) | (1U << 5) | (1U << 4)) +#define CNFGA_ID_SHIFT 4 +#define CNFGA_ID_16 (00U << CNFGA_ID_SHIFT) +#define CNFGA_ID_8 (01U << CNFGA_ID_SHIFT) +#define CNFGA_ID_32 (02U << CNFGA_ID_SHIFT) +/* #define CNFGA_reserved (1U << 3) */ +#define CNFGA_nBYTEINTRANS (1U << 2) +#define CNFGA_PWORDLEFT ((1U << 1) | (1U << 0)) + +/* ECP Configuration Register B */ +#define CNFGB_COMPRESS (1U << 7) +#define CNFGB_INTRVAL (1U << 6) +#define CNFGB_IRQ_MASK ((1U << 5) | (1U << 4) | (1U << 3)) +#define CNFGB_IRQ_SHIFT 3 +#define CNFGB_DMA_MASK ((1U << 2) | (1U << 1) | (1U << 0)) +#define CNFGB_DMA_SHIFT 0 + +/* Extended Control Register */ +#define ECR_MODE_MASK ((1U << 7) | (1U << 6) | (1U << 5)) +#define ECR_MODE_SHIFT 5 +#define ECR_MODE_SPP (00U << ECR_MODE_SHIFT) +#define ECR_MODE_PS2 (01U << ECR_MODE_SHIFT) +#define ECR_MODE_PPF (02U << ECR_MODE_SHIFT) +#define ECR_MODE_ECP (03U << ECR_MODE_SHIFT) +#define ECR_MODE_EPP (04U << ECR_MODE_SHIFT) +/* #define ECR_MODE_reserved (05U << ECR_MODE_SHIFT) */ +#define ECR_MODE_TST (06U << ECR_MODE_SHIFT) +#define ECR_MODE_CFG (07U << ECR_MODE_SHIFT) +#define ECR_nERRINTR (1U << 4) +#define ECR_DMAEN (1U << 3) +#define ECR_SERVINTR (1U << 2) +#define ECR_F_FULL (1U << 1) +#define ECR_F_EMPTY (1U << 0) + +/*--- Private data -----------------------------------------------------*/ + +/** + * enum parport_ip32_irq_mode - operation mode of interrupt handler + * @PARPORT_IP32_IRQ_FWD forward interrupt to the upper parport layer + * @PARPORT_IP32_IRQ_HERE interrupt is handled locally + */ +enum parport_ip32_irq_mode { PARPORT_IP32_IRQ_FWD, PARPORT_IP32_IRQ_HERE }; + +/** + * struct parport_ip32_private - private stuff for &struct parport + * @regs: register addresses + * @dcr_cache: cached contents of DCR + * @dcr_writable: bit mask of writable DCR bits + * @pword: number of bytes per PWord + * @fifo_depth: number of PWords that FIFO will hold + * @readIntrThreshold: minimum number of PWords we can read + * if we get an interrupt + * @writeIntrThreshold: minimum number of PWords we can write + * if we get an interrupt + * @irq_mode: operation mode of interrupt handler for this port + * @irq_complete: mutex used to wait for an interrupt to occur + */ +struct parport_ip32_private { + struct parport_ip32_regs regs; + unsigned int dcr_cache; + unsigned int dcr_writable; + unsigned int pword; + unsigned int fifo_depth; + unsigned int readIntrThreshold; + unsigned int writeIntrThreshold; + enum parport_ip32_irq_mode irq_mode; + struct completion irq_complete; +}; + +/*--- I/O register access functions ------------------------------------*/ + +/* FIXME - Use io{read,write}8 (and _rep) when available on MIPS? */ +/* FIXME - Are the memory barriers really needed? */ + +/** + * parport_ip32_in - read a register + * @addr: address of register + */ +static inline u8 parport_ip32_in(void __iomem *addr) +{ + u8 val = readb(addr); + rmb(); + return val; +} + +/** + * parport_ip32_out - write some value to a register + * @val: value to write + * @addr: address of register + */ +static inline void parport_ip32_out(u8 val, void __iomem *addr) +{ + writeb(val, addr); + wmb(); +} + +/** + * parport_ip32_in_rep - read multiple values from a register + * @addr: address of register + * @buf: buffer to store read values + * @count: number of bytes to read + */ +static inline void parport_ip32_in_rep(void __iomem *addr, + void *buf, unsigned long count) +{ + readsb(addr, buf, count); + rmb(); +} + +/** + * parport_ip32_out_rep - write multiple values to a register + * @addr: address of register + * @buf: buffer of values to write + * @count: number of bytes to write + */ +static inline void parport_ip32_out_rep(void __iomem *addr, + const void *buf, unsigned long count) +{ + writesb(addr, buf, count); + wmb(); +} + +/*--- Debug code -------------------------------------------------------*/ + +/** + * pr_debug1 - print debug messages + * + * This is like pr_debug(), but is defined for %DEBUG_PARPORT_IP32 >= 1 + */ +#if DEBUG_PARPORT_IP32 >= 1 +# define pr_debug1(...) printk(KERN_DEBUG __VA_ARGS__) +#else /* DEBUG_PARPORT_IP32 < 1 */ +# define pr_debug1(...) +#endif + +/** + * pr_trace, pr_trace1 - trace function calls + * @p: pointer to &struct parport + * @fmt: printk format string + * @...: parameters for format string + * + * Macros used to trace function calls. The given string is formatted after + * function name. pr_trace() uses pr_debug(), and pr_trace1() uses + * pr_debug1(). __pr_trace() is the low-level macro and is not to be used + * directly. + */ +#define __pr_trace(pr, p, fmt, ...) \ + pr("%s: %s" fmt "\n", \ + ({ const struct parport *__p = (p); \ + __p? __p->name: "parport_ip32"; }), \ + __func__ , ##__VA_ARGS__) +#define pr_trace(p, fmt, ...) __pr_trace(pr_debug, p, fmt , ##__VA_ARGS__) +#define pr_trace1(p, fmt, ...) __pr_trace(pr_debug1, p, fmt , ##__VA_ARGS__) + +/** + * __pr_probe, pr_probe - print message if @verbose_probing is true + * @p: pointer to &struct parport + * @fmt: printk format string + * @...: parameters for format string + * + * For new lines, use pr_probe(). Use __pr_probe() for continued lines. + */ +#define __pr_probe(...) \ + do { if (verbose_probing) printk(__VA_ARGS__); } while (0) +#define pr_probe(p, fmt, ...) \ + __pr_probe(KERN_INFO PPIP32 "0x%lx: " fmt, (p)->base , ##__VA_ARGS__) + +/** + * parport_ip32_dump_state - print register status of parport + * @p: pointer to &struct parport + * @str: string to add in message + * @show_ecp_config: shall we dump ECP configuration registers too? + * + * This function is only here for debugging purpose, and should be used with + * care. Reading the parallel port registers may have undesired side effects. + * Especially if @show_ecp_config is true, the parallel port is resetted. + * This function is only defined if %DEBUG_PARPORT_IP32 >= 2. + */ +#if DEBUG_PARPORT_IP32 >= 2 +static void parport_ip32_dump_state(struct parport *p, char *str, + unsigned int show_ecp_config) +{ + /* here's hoping that reading these ports won't side-effect + * anything underneath */ + struct parport_ip32_private * const priv = p->physport->private_data; + unsigned int i; + + printk(KERN_DEBUG PPIP32 "%s: state (%s):\n", p->name, str); + { + static const char ecr_modes[8][4] = {"SPP", "PS2", "PPF", + "ECP", "EPP", "???", + "TST", "CFG"}; + unsigned int ecr = parport_ip32_in(priv->regs.ecr); + printk(KERN_DEBUG PPIP32 " ecr=0x%02x", ecr); + printk(" %s", + ecr_modes[(ecr & ECR_MODE_MASK) >> ECR_MODE_SHIFT]); + if (ecr & ECR_nERRINTR) printk(",nErrIntrEn"); + if (ecr & ECR_DMAEN) printk(",dmaEn"); + if (ecr & ECR_SERVINTR) printk(",serviceIntr"); + if (ecr & ECR_F_FULL) printk(",f_full"); + if (ecr & ECR_F_EMPTY) printk(",f_empty"); + printk("\n"); + } + if (show_ecp_config) { + unsigned int oecr, cnfgA, cnfgB; + oecr = parport_ip32_in(priv->regs.ecr); + parport_ip32_out(ECR_MODE_PS2, priv->regs.ecr); + parport_ip32_out(ECR_MODE_CFG, priv->regs.ecr); + cnfgA = parport_ip32_in(priv->regs.cnfgA); + cnfgB = parport_ip32_in(priv->regs.cnfgB); + parport_ip32_out(ECR_MODE_PS2, priv->regs.ecr); + parport_ip32_out(oecr, priv->regs.ecr); + printk(KERN_DEBUG PPIP32 " cnfgA=0x%02x", cnfgA); + printk(" ISA-%s", (cnfgA & CNFGA_IRQ)? "Level": "Pulses"); + switch (cnfgA & CNFGA_ID_MASK) { + case CNFGA_ID_8: printk(",8 bits"); break; + case CNFGA_ID_16: printk(",16 bits"); break; + case CNFGA_ID_32: printk(",32 bits"); break; + default: printk(",unknown ID"); break; + } + if (!(cnfgA & CNFGA_nBYTEINTRANS)) printk(",ByteInTrans"); + if ((cnfgA & CNFGA_ID_MASK) != CNFGA_ID_8) { + printk(",%d byte%s left", cnfgA & CNFGA_PWORDLEFT, + ((cnfgA & CNFGA_PWORDLEFT) > 1)? "s": ""); + } + printk("\n"); + printk(KERN_DEBUG PPIP32 " cnfgB=0x%02x", cnfgB); + printk(" irq=%u,dma=%u", + (cnfgB & CNFGB_IRQ_MASK) >> CNFGB_IRQ_SHIFT, + (cnfgB & CNFGB_DMA_MASK) >> CNFGB_DMA_SHIFT); + printk(",intrValue=%d", !!(cnfgB & CNFGB_INTRVAL)); + if (cnfgB & CNFGB_COMPRESS) printk(",compress"); + printk("\n"); + } + for (i = 0; i < 2; i++) { + unsigned int dcr = + i? priv->dcr_cache: parport_ip32_in(priv->regs.dcr); + printk(KERN_DEBUG PPIP32 " dcr(%s)=0x%02x", + i? "soft": "hard", dcr); + printk(" %s", (dcr & DCR_DIR)? "rev": "fwd"); + if (dcr & DCR_IRQ) printk(",ackIntEn"); + if (!(dcr & DCR_SELECT)) printk(",nSelectIn"); + if (dcr & DCR_nINIT) printk(",nInit"); + if (!(dcr & DCR_AUTOFD)) printk(",nAutoFD"); + if (!(dcr & DCR_STROBE)) printk(",nStrobe"); + printk("\n"); + } +#define sep (f++? ',': ' ') + { + unsigned int f = 0; + unsigned int dsr = parport_ip32_in(priv->regs.dsr); + printk(KERN_DEBUG PPIP32 " dsr=0x%02x", dsr); + if (!(dsr & DSR_nBUSY)) printk("%cBusy", sep); + if (dsr & DSR_nACK) printk("%cnAck", sep); + if (dsr & DSR_PERROR) printk("%cPError", sep); + if (dsr & DSR_SELECT) printk("%cSelect", sep); + if (dsr & DSR_nFAULT) printk("%cnFault", sep); + if (!(dsr & DSR_nPRINT)) printk("%c(Print)", sep); + if (dsr & DSR_TIMEOUT) printk("%cTimeout", sep); + printk("\n"); + } +#undef sep +} +#else /* DEBUG_PARPORT_IP32 < 2 */ +#define parport_ip32_dump_state(...) +#endif + +/** + * CHECK_EXTRA_BITS - track and log extra bits + * @p: pointer to &struct parport + * @b: byte to inspect + * @m: bit mask of authorized bits + * + * This is used to track and log extra bits that should not be there in + * parport_ip32_write_control() and parport_ip32_frob_control(). It is only + * defined if %DEBUG_PARPORT_IP32 >= 1. + */ +#if DEBUG_PARPORT_IP32 >= 1 +#define CHECK_EXTRA_BITS(p, b, m) \ + do { \ + unsigned int __b = (b), __m = (m); \ + if (__b & ~__m) \ + pr_debug1(PPIP32 "%s: extra bits in %s(%s): " \ + "0x%02x/0x%02x\n", \ + (p)->name, __func__, #b, __b, __m); \ + } while (0) +#else /* DEBUG_PARPORT_IP32 < 1 */ +#define CHECK_EXTRA_BITS(...) +#endif + +/*--- IP32 parallel port DMA operations --------------------------------*/ + +/** + * struct parport_ip32_dma_data - private data needed for DMA operation + * @dir: DMA direction (from or to device) + * @buf: buffer physical address + * @len: buffer length + * @next: address of next bytes to DMA transfer + * @left: number of bytes remaining + * @ctx: next context to write (0: context_a; 1: context_b) + * @lock: mutex for parport_ip32_dma_setup_context() + * @noirq: mutex used to ensure that IRQs are not disabled twice + */ +struct parport_ip32_dma_data { + enum dma_data_direction dir; + dma_addr_t buf; + dma_addr_t next; + size_t len; + size_t left; + unsigned int ctx; + struct semaphore lock; + struct semaphore noirq; +}; +static struct parport_ip32_dma_data parport_ip32_dma; + +/** + * parport_ip32_setup_context - setup next DMA context + * @limit: maximum data size for the context + * + * The alignment constraints must be verified in caller function, and the + * parameter @limit must be set accordingly. + */ +static inline void parport_ip32_dma_setup_context(unsigned int limit) +{ + if (down_trylock(&parport_ip32_dma.lock)) { + /* Come back later please. The MACE keeps sending interrupts + * when a context is invalid, so there is no problem with this + * early return. */ + return; + } + if (parport_ip32_dma.left > 0) { + volatile u64 __iomem *ctxreg = (parport_ip32_dma.ctx == 0)? + &mace->perif.ctrl.parport.context_a: + &mace->perif.ctrl.parport.context_b; + u64 count; + u64 ctxval; + if (parport_ip32_dma.left <= limit) { + count = parport_ip32_dma.left; + ctxval = MACEPAR_CONTEXT_LASTFLAG; + } else { + count = limit; + ctxval = 0; + } + + pr_trace(NULL, + "(%u): 0x%04x:0x%04x, %u -> %u%s", + limit, + (unsigned int)parport_ip32_dma.buf, + (unsigned int)parport_ip32_dma.next, + (unsigned int)count, + parport_ip32_dma.ctx, ctxval? "*": ""); + + ctxval |= parport_ip32_dma.next & + MACEPAR_CONTEXT_BASEADDR_MASK; + ctxval |= ((count - 1) << MACEPAR_CONTEXT_DATALEN_SHIFT) & + MACEPAR_CONTEXT_DATALEN_MASK; + writeq(ctxval, ctxreg); + wmb(); + parport_ip32_dma.next += count; + parport_ip32_dma.left -= count; + parport_ip32_dma.ctx ^= 1U; + } + /* If there is nothing more to send, disable IRQs to avoid to + * face an IRQ storm which can lock the machine. Disable them + * only once. */ + if (parport_ip32_dma.left == 0 + && !down_trylock(&parport_ip32_dma.noirq)) { + pr_debug(PPIP32 "IRQ off (ctx)\n"); + disable_irq_nosync(MACEISA_PAR_CTXA_IRQ); + disable_irq_nosync(MACEISA_PAR_CTXB_IRQ); + } + /* Make sure that parport_ip32_dma is actually written */ + barrier(); + up(&parport_ip32_dma.lock); +} + +/** + * parport_ip32_dma_interrupt - DMA interrupt handler + */ +static irqreturn_t parport_ip32_dma_interrupt(int irq, void *dev_id, + struct pt_regs *regs) +{ + if (parport_ip32_dma.left) + pr_trace(NULL, "(%d): ctx=%d", irq, parport_ip32_dma.ctx); + parport_ip32_dma_setup_context(MACEPAR_CONTEXT_DATA_BOUND); + return IRQ_HANDLED; +} + +#if DEBUG_PARPORT_IP32 +static irqreturn_t parport_ip32_merr_interrupt(int irq, void *dev_id, + struct pt_regs *regs) +{ + pr_trace1(NULL, "(%d)", irq); + return IRQ_HANDLED; +} +#endif + +/** + * parport_ip32_dma_start - begins a DMA transfer + * @dir: DMA direction: DMA_TO_DEVICE or DMA_FROM_DEVICE + * @addr: pointer to data buffer + * @count: buffer size + * + * Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be + * correctly balanced. + */ +static int parport_ip32_dma_start(enum dma_data_direction dir, + void *addr, size_t count) +{ + unsigned int limit; + u64 ctrl; + + pr_trace(NULL, "(%d, %lu)", dir, (unsigned long)count); + + /* FIXME - add support for DMA_FROM_DEVICE. In this case, buffer must + * be 64 bytes aligned. */ + BUG_ON(dir != DMA_TO_DEVICE); + + /* Reset DMA controller, and enable IRQs if needed */ + ctrl = MACEPAR_CTLSTAT_RESET; + writeq(ctrl, &mace->perif.ctrl.parport.cntlstat); + wmb(); + if (down_trylock(&parport_ip32_dma.noirq)) { + /* Failing to acquire lock means that IRQs were actually + * disabled. This should normally not happen. Re-enable + * interrupts anyway. */ + printk(KERN_DEBUG PPIP32 "enabling DMA interrupts\n"); + pr_debug(PPIP32 "IRQ on (start)\n"); + enable_irq(MACEISA_PAR_CTXA_IRQ); + enable_irq(MACEISA_PAR_CTXB_IRQ); + } + up(&parport_ip32_dma.noirq); + + /* Prepare DMA pointers */ + parport_ip32_dma.dir = dir; + parport_ip32_dma.buf = dma_map_single(NULL, addr, count, dir); + parport_ip32_dma.len = count; + parport_ip32_dma.next = parport_ip32_dma.buf; + parport_ip32_dma.left = parport_ip32_dma.len; + parport_ip32_dma.ctx = 0; + + /* Setup DMA direction and first two contexts */ + ctrl = (dir == DMA_TO_DEVICE)? 0: MACEPAR_CTLSTAT_DIRECTION; + writeq(ctrl, &mace->perif.ctrl.parport.cntlstat); + wmb(); + /* Single transfer should not cross a 4K page boundary */ + limit = MACEPAR_CONTEXT_DATA_BOUND - + (parport_ip32_dma.next & (MACEPAR_CONTEXT_DATA_BOUND - 1)); + parport_ip32_dma_setup_context(limit); + parport_ip32_dma_setup_context(MACEPAR_CONTEXT_DATA_BOUND); + + /* Real start of DMA transfer */ + ctrl |= MACEPAR_CTLSTAT_ENABLE; + writeq(ctrl, &mace->perif.ctrl.parport.cntlstat); + wmb(); + + return 0; +} + +/** + * parport_ip32_dma_stop - ends a running DMA transfer + * + * Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be + * correctly balanced. + */ +static void parport_ip32_dma_stop(void) +{ + u64 ctx_a; + u64 ctx_b; + u64 ctrl; + u64 diag; + size_t res[2]; /* {[0] = res_a, [1] = res_b} */ + + pr_trace(NULL, "()"); + + /* Disable IRQs */ + if (!down_trylock(&parport_ip32_dma.noirq)) { + pr_debug(PPIP32 "IRQ off (stop)\n"); + disable_irq_nosync(MACEISA_PAR_CTXA_IRQ); + disable_irq_nosync(MACEISA_PAR_CTXB_IRQ); + } + /* Force IRQ synchronization, even if the IRQs were disabled + * elsewhere. */ + synchronize_irq(MACEISA_PAR_CTXA_IRQ); + synchronize_irq(MACEISA_PAR_CTXB_IRQ); + + /* Stop DMA transfer */ + ctrl = readq(&mace->perif.ctrl.parport.cntlstat); + ctrl &= ~MACEPAR_CTLSTAT_ENABLE; + writeq(ctrl, &mace->perif.ctrl.parport.cntlstat); + wmb(); + + /* Adjust residue (parport_ip32_dma.left) */ + ctx_a = readq(&mace->perif.ctrl.parport.context_a); + ctx_b = readq(&mace->perif.ctrl.parport.context_b); + ctrl = readq(&mace->perif.ctrl.parport.cntlstat); + diag = readq(&mace->perif.ctrl.parport.diagnostic); + res[0] = (ctrl & MACEPAR_CTLSTAT_CTXA_VALID)? + 1 + ((ctx_a & MACEPAR_CONTEXT_DATALEN_MASK) >> + MACEPAR_CONTEXT_DATALEN_SHIFT): + 0; + res[1] = (ctrl & MACEPAR_CTLSTAT_CTXB_VALID)? + 1 + ((ctx_b & MACEPAR_CONTEXT_DATALEN_MASK) >> + MACEPAR_CONTEXT_DATALEN_SHIFT): + 0; + if (diag & MACEPAR_DIAG_DMACTIVE) { + res[(diag & MACEPAR_DIAG_CTXINUSE) != 0] = + 1 + ((diag & MACEPAR_DIAG_CTRMASK) >> + MACEPAR_DIAG_CTRSHIFT); + } + parport_ip32_dma.left += res[0] + res[1]; + + /* Reset DMA controller, and re-enable IRQs */ + ctrl = MACEPAR_CTLSTAT_RESET; + writeq(ctrl, &mace->perif.ctrl.parport.cntlstat); + wmb(); + pr_debug(PPIP32 "IRQ on (stop)\n"); + enable_irq(MACEISA_PAR_CTXA_IRQ); + enable_irq(MACEISA_PAR_CTXB_IRQ); + up(&parport_ip32_dma.noirq); + + dma_unmap_single(NULL, parport_ip32_dma.buf, parport_ip32_dma.len, + parport_ip32_dma.dir); +} + +/** + * parport_ip32_dma_get_residue - get residue from last DMA transfer + * + * Returns the number of byte remaining from last DMA transfer. + */ +static inline size_t parport_ip32_dma_get_residue(void) +{ + return parport_ip32_dma.left; +} + +/** + * parport_ip32_dma_register - initialize DMA engine + */ +static int parport_ip32_dma_register(void) +{ + int err; + + /* Reset DMA controller */ + writeq(MACEPAR_CTLSTAT_RESET, &mace->perif.ctrl.parport.cntlstat); + wmb(); + init_MUTEX(&parport_ip32_dma.lock); + init_MUTEX(&parport_ip32_dma.noirq); + + /* Request IRQs */ + err = request_irq(MACEISA_PAR_CTXA_IRQ, parport_ip32_dma_interrupt, + 0, "parport_ip32", NULL); + if (err) + goto fail_a; + err = request_irq(MACEISA_PAR_CTXB_IRQ, parport_ip32_dma_interrupt, + 0, "parport_ip32", NULL); + if (err) + goto fail_b; +#if DEBUG_PARPORT_IP32 + /* FIXME - what is this IRQ for? */ + err = request_irq(MACEISA_PAR_MERR_IRQ, parport_ip32_merr_interrupt, + 0, "parport_ip32", NULL); + if (err) + goto fail_merr; +#endif + return 0; + +#if DEBUG_PARPORT_IP32 +fail_merr: + free_irq(MACEISA_PAR_CTXB_IRQ, NULL); +#endif +fail_b: + free_irq(MACEISA_PAR_CTXA_IRQ, NULL); +fail_a: + return err; +} + +/** + * parport_ip32_dma_unregister - release and free resources for DMA engine + */ +static void parport_ip32_dma_unregister(void) +{ +#if DEBUG_PARPORT_IP32 + free_irq(MACEISA_PAR_MERR_IRQ, NULL); +#endif + free_irq(MACEISA_PAR_CTXB_IRQ, NULL); + free_irq(MACEISA_PAR_CTXA_IRQ, NULL); +} + +/*--- Interrupt handlers and associates --------------------------------*/ + +/** + * parport_ip32_wakeup - wakes up code waiting for an interrupt + * @p: pointer to &struct parport + */ +static inline void parport_ip32_wakeup(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + complete(&priv->irq_complete); +} + +/** + * parport_ip32_interrupt - interrupt handler + * + * Caught interrupts are forwarded to the upper parport layer if IRQ_mode is + * %PARPORT_IP32_IRQ_FWD. + */ +static irqreturn_t parport_ip32_interrupt(int irq, void *dev_id, + struct pt_regs *regs) +{ + struct parport * const p = dev_id; + struct parport_ip32_private * const priv = p->physport->private_data; + enum parport_ip32_irq_mode irq_mode = priv->irq_mode; + barrier(); /* ensures that priv->irq_mode is read */ + switch (irq_mode) { + case PARPORT_IP32_IRQ_FWD: + parport_generic_irq(irq, p, regs); + break; + case PARPORT_IP32_IRQ_HERE: + parport_ip32_wakeup(p); + break; + } + return IRQ_HANDLED; +} + +/** + * parport_ip32_timeout - timeout handler + */ +static void parport_ip32_timeout(unsigned long data) +{ + struct parport * const p = (struct parport *)data; + parport_ip32_wakeup(p); +} + +/*--- Some utility function to manipulate ECR register -----------------*/ + +/** + * parport_ip32_read_econtrol - read contents of the ECR register + * @p: pointer to &struct parport + */ +static inline unsigned int parport_ip32_read_econtrol(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_in(priv->regs.ecr); +} + +/** + * parport_ip32_write_econtrol - write new contents to the ECR register + * @p: pointer to &struct parport + * @c: new value to write + */ +static inline void parport_ip32_write_econtrol(struct parport *p, + unsigned int c) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + parport_ip32_out(c, priv->regs.ecr); +} + +/** + * parport_ip32_frob_econtrol - change bits from the ECR register + * @p: pointer to &struct parport + * @mask: bit mask of bits to change + * @val: new value for changed bits + * + * Read from the ECR, mask out the bits in @mask, exclusive-or with the bits + * in @val, and write the result to the ECR. + */ +static inline void parport_ip32_frob_econtrol(struct parport *p, + unsigned int mask, + unsigned int val) +{ + unsigned int c; + c = (parport_ip32_read_econtrol(p) & ~mask) ^ val; + parport_ip32_write_econtrol(p, c); +} + +/** + * parport_ip32_set_mode - change mode of ECP port + * @p: pointer to &struct parport + * @mode: new mode to write in ECR + * + * ECR is reset in a sane state (interrupts and DMA disabled), and placed in + * mode @mode. Go through PS2 mode if needed. + */ +static inline void parport_ip32_set_mode(struct parport *p, unsigned int mode) +{ + unsigned int omode; + + mode &= ECR_MODE_MASK; + omode = parport_ip32_read_econtrol(p) & ECR_MODE_MASK; + + if (!(mode == ECR_MODE_SPP || mode == ECR_MODE_PS2 + || omode == ECR_MODE_SPP || omode == ECR_MODE_PS2)) { + /* We have to go through PS2 mode */ + unsigned int ecr = ECR_MODE_PS2 | ECR_nERRINTR | ECR_SERVINTR; + parport_ip32_write_econtrol(p, ecr); + } + parport_ip32_write_econtrol(p, mode | ECR_nERRINTR | ECR_SERVINTR); +} + +/*--- Basic functions needed for parport -------------------------------*/ + +/** + * parport_ip32_read_data - return current contents of the DATA register + * @p: pointer to &struct parport + */ +static inline unsigned char parport_ip32_read_data(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_in(priv->regs.data); +} + +/** + * parport_ip32_write_data - set new contents for the DATA register + * @p: pointer to &struct parport + * @d: new value to write + */ +static inline void parport_ip32_write_data(struct parport *p, unsigned char d) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + parport_ip32_out(d, priv->regs.data); +} + +/** + * parport_ip32_read_status - return current contents of the DSR register + * @p: pointer to &struct parport + */ +static inline unsigned char parport_ip32_read_status(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_in(priv->regs.dsr); +} + +/** + * __parport_ip32_read_control - return cached contents of the DCR register + * @p: pointer to &struct parport + */ +static inline unsigned int __parport_ip32_read_control(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return priv->dcr_cache; /* use soft copy */ +} + +/** + * parport_ip32_read_control - return cached contents of the DCR register + * @p: pointer to &struct parport + * + * The return value is masked so as to only return the value of %DCR_STROBE, + * %DCR_AUTOFD, %DCR_nINIT, and %DCR_SELECT. + */ +static inline unsigned char parport_ip32_read_control(struct parport *p) +{ + const unsigned int rm = + DCR_STROBE | DCR_AUTOFD | DCR_nINIT | DCR_SELECT; + return __parport_ip32_read_control(p) & rm; +} + +/** + * __parport_ip32_write_control - set new contents for the DCR register + * @p: pointer to &struct parport + * @c: new value to write + */ +static inline void __parport_ip32_write_control(struct parport *p, + unsigned int c) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + CHECK_EXTRA_BITS(p, c, priv->dcr_writable); + c &= priv->dcr_writable; /* only writable bits */ + parport_ip32_out(c, priv->regs.dcr); + priv->dcr_cache = c; /* update soft copy */ +} + +/** + * __parport_ip32_frob_control - change bits from the DCR register + * @p: pointer to &struct parport + * @mask: bit mask of bits to change + * @val: new value for changed bits + * + * This is equivalent to read from the DCR, mask out the bits in @mask, + * exclusive-or with the bits in @val, and write the result to the DCR. + * Actually, the cached contents of the DCR is used. + */ +static inline void __parport_ip32_frob_control(struct parport *p, + unsigned int mask, + unsigned int val) +{ + unsigned int c; + c = (__parport_ip32_read_control(p) & ~mask) ^ val; + __parport_ip32_write_control(p, c); +} + +/** + * parport_ip32_write_control - set new contents for the DCR register + * @p: pointer to &struct parport + * @c: new value to write + * + * The value is masked so as to only change the value of %DCR_STROBE, + * %DCR_AUTOFD, %DCR_nINIT, and %DCR_SELECT. + */ +static inline void parport_ip32_write_control(struct parport *p, + unsigned char c) +{ + const unsigned int wm = + DCR_STROBE | DCR_AUTOFD | DCR_nINIT | DCR_SELECT; + CHECK_EXTRA_BITS(p, c, wm); + __parport_ip32_frob_control(p, wm, c & wm); +} + +/** + * parport_ip32_frob_control - change bits from the DCR register + * @p: pointer to &struct parport + * @mask: bit mask of bits to change + * @val: new value for changed bits + * + * This differs from __parport_ip32_frob_control() in that it only allows to + * change the value of %DCR_STROBE, %DCR_AUTOFD, %DCR_nINIT, and %DCR_SELECT. + */ +static inline unsigned char parport_ip32_frob_control(struct parport *p, + unsigned char mask, + unsigned char val) +{ + const unsigned int wm = + DCR_STROBE | DCR_AUTOFD | DCR_nINIT | DCR_SELECT; + CHECK_EXTRA_BITS(p, mask, wm); + CHECK_EXTRA_BITS(p, val, wm); + __parport_ip32_frob_control(p, mask & wm, val & wm); + return parport_ip32_read_control(p); +} + +/** + * parport_ip32_disable_irq - disable interrupts on the rising edge of nACK + * @p: pointer to &struct parport + */ +static inline void parport_ip32_disable_irq(struct parport *p) +{ + __parport_ip32_frob_control(p, DCR_IRQ, 0); +} + +/** + * parport_ip32_enable_irq - enable interrupts on the rising edge of nACK + * @p: pointer to &struct parport + */ +static inline void parport_ip32_enable_irq(struct parport *p) +{ + __parport_ip32_frob_control(p, DCR_IRQ, DCR_IRQ); +} + +/** + * parport_ip32_data_forward - enable host-to-peripheral communications + * @p: pointer to &struct parport + * + * Enable the data line drivers, for 8-bit host-to-peripheral communications. + */ +static inline void parport_ip32_data_forward(struct parport *p) +{ + __parport_ip32_frob_control(p, DCR_DIR, 0); +} + +/** + * parport_ip32_data_reverse - enable peripheral-to-host communications + * @p: pointer to &struct parport + * + * Place the data bus in a high impedance state, if @p->modes has the + * PARPORT_MODE_TRISTATE bit set. + */ +static inline void parport_ip32_data_reverse(struct parport *p) +{ + __parport_ip32_frob_control(p, DCR_DIR, DCR_DIR); +} + +/** + * parport_ip32_init_state - for core parport code + */ +static inline void parport_ip32_init_state(struct pardevice *dev, + struct parport_state *s) +{ + s->u.ip32.dcr = DCR_SELECT | DCR_nINIT; + s->u.ip32.ecr = ECR_MODE_PS2 | ECR_nERRINTR | ECR_SERVINTR; +} + +/** + * parport_ip32_save_state - for core parport code + */ +static inline void parport_ip32_save_state(struct parport *p, + struct parport_state *s) +{ + s->u.ip32.dcr = __parport_ip32_read_control(p); + s->u.ip32.ecr = parport_ip32_read_econtrol(p); +} + +/** + * parport_ip32_restore_state - for core parport code + */ +static inline void parport_ip32_restore_state(struct parport *p, + struct parport_state *s) +{ + parport_ip32_set_mode(p, s->u.ip32.ecr & ECR_MODE_MASK); + parport_ip32_write_econtrol(p, s->u.ip32.ecr); + __parport_ip32_write_control(p, s->u.ip32.dcr); +} + +/*--- EPP mode functions -----------------------------------------------*/ + +/** + * parport_ip32_clear_epp_timeout - clear Timeout bit in EPP mode + * @p: pointer to &struct parport + * + * Returns 1 if the Timeout bit is clear, and 0 otherwise. + */ +static unsigned int parport_ip32_clear_epp_timeout(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + unsigned int cleared; + + if (!(parport_ip32_read_status(p) & DSR_TIMEOUT)) { + cleared = 1; + } else { + unsigned int r; + /* To clear timeout some chips require double read */ + parport_ip32_read_status(p); + r = parport_ip32_read_status(p); + /* Some reset by writing 1 */ + parport_ip32_out(r | DSR_TIMEOUT, priv->regs.dsr); + /* Others by writing 0 */ + parport_ip32_out(r & ~DSR_TIMEOUT, priv->regs.dsr); + + r = parport_ip32_read_status(p); + cleared = !(r & DSR_TIMEOUT); + } + + pr_trace(p, "(): %s", cleared? "cleared": "failed"); + return cleared; +} + +/** + * parport_ip32_epp_read - generic EPP read function + * @eppreg: I/O register to read from + * @p: pointer to &struct parport + * @buf: buffer to store read data + * @len: length of buffer @buf + * @flags: may be PARPORT_EPP_FAST + */ +static inline size_t parport_ip32_epp_read(void __iomem *eppreg, + struct parport *p, void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + size_t got; + parport_ip32_set_mode(p, ECR_MODE_EPP); + parport_ip32_data_reverse(p); + parport_ip32_write_control(p, DCR_nINIT); + if ((flags & PARPORT_EPP_FAST) && (len > 1)) { + parport_ip32_in_rep(eppreg, buf, len); + if (parport_ip32_in(priv->regs.dsr) & DSR_TIMEOUT) { + parport_ip32_clear_epp_timeout(p); + return -EIO; + } + got = len; + } else { + u8 *bufp = buf; + for (got = 0; got < len; got++) { + *bufp++ = parport_ip32_in(eppreg); + if (parport_ip32_in(priv->regs.dsr) & DSR_TIMEOUT) { + parport_ip32_clear_epp_timeout(p); + break; + } + } + } + parport_ip32_data_forward(p); + parport_ip32_set_mode(p, ECR_MODE_PS2); + return got; +} + +/** + * parport_ip32_epp_write - generic EPP write function + * @eppreg: I/O register to write to + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * @flags: may be PARPORT_EPP_FAST + */ +static inline size_t parport_ip32_epp_write(void __iomem *eppreg, + struct parport *p, const void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + size_t written; + parport_ip32_set_mode(p, ECR_MODE_EPP); + parport_ip32_data_forward(p); + parport_ip32_write_control(p, DCR_nINIT); + if ((flags & PARPORT_EPP_FAST) && (len > 1)) { + parport_ip32_out_rep(eppreg, buf, len); + if (parport_ip32_in(priv->regs.dsr) & DSR_TIMEOUT) { + parport_ip32_clear_epp_timeout(p); + return -EIO; + } + written = len; + } else { + const u8 *bufp = buf; + for (written = 0; written < len; written++) { + parport_ip32_out(*bufp++, eppreg); + if (parport_ip32_in(priv->regs.dsr) & DSR_TIMEOUT) { + parport_ip32_clear_epp_timeout(p); + break; + } + } + } + parport_ip32_set_mode(p, ECR_MODE_PS2); + return written; +} + +/** + * parport_ip32_epp_read_data - read a block of data in EPP mode + */ +static size_t parport_ip32_epp_read_data(struct parport *p, void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_epp_read(priv->regs.eppData0, p, buf, len, flags); +} + +/** + * parport_ip32_epp_write_data - write a block of data in EPP mode + */ +static size_t parport_ip32_epp_write_data(struct parport *p, const void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_epp_write(priv->regs.eppData0, p, buf, len, flags); +} + +/** + * parport_ip32_epp_read_addr - read a block of addresses in EPP mode + */ +static size_t parport_ip32_epp_read_addr(struct parport *p, void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_epp_read(priv->regs.eppAddr, p, buf, len, flags); +} + +/** + * parport_ip32_epp_write_addr - write a block of addresses in EPP mode + */ +static size_t parport_ip32_epp_write_addr(struct parport *p, const void *buf, + size_t len, int flags) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + return parport_ip32_epp_write(priv->regs.eppAddr, p, buf, len, flags); +} + +/*--- ECP mode functions (FIFO) ----------------------------------------*/ + +/** + * parport_ip32_fifo_wait_break - check if the waiting function should return + * @p: pointer to &struct parport + * @expire: timeout expiring date, in jiffies + * + * parport_ip32_fifo_wait_break() checks if the waiting function should return + * immediately or not. The break conditions are: + * - expired timeout; + * - a pending signal; + * - nFault asserted low. + * This function also calls cond_resched(). + */ +static inline unsigned int parport_ip32_fifo_wait_break(struct parport *p, + unsigned long expire) +{ + cond_resched(); + if (time_after(jiffies, expire)) { + printk(KERN_DEBUG PPIP32 + "%s: FIFO write timed out\n", p->name); + return 1; + } + if (signal_pending(current)) { + printk(KERN_DEBUG PPIP32 + "%s: Signal pending\n", p->name); + return 1; + } + if (!(parport_ip32_read_status(p) & DSR_nFAULT)) { + printk(KERN_DEBUG PPIP32 + "%s: nFault asserted low\n", p->name); + return 1; + } + return 0; +} + +/** + * parport_ip32_fwp_wait_polling - wait for FIFO to empty (polling) + * @p: pointer to &struct parport + * + * Returns the number of bytes that can safely be written in the FIFO. A + * return value of zero means that the calling function should terminate as + * fast as possible. + */ +static inline unsigned int parport_ip32_fwp_wait_polling(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport * const physport = p->physport; + unsigned long expire; + unsigned int count; + unsigned int ecr; + + expire = jiffies + physport->cad->timeout; + count = 0; + while (1) { + if (parport_ip32_fifo_wait_break(p, expire)) + break; + + /* Check FIFO state. We do nothing when the FIFO is nor full, + * nor empty. It appears that the FIFO full bit is not always + * reliable, the FIFO state is sometimes wrongly reported, and + * the chip gets confused if we give it another byte. */ + ecr = parport_ip32_read_econtrol(p); + if (ecr & ECR_F_EMPTY) { + /* FIFO is empty, fill it up */ + count = priv->fifo_depth; + break; + } + + /* Wait a moment... */ + udelay(FIFO_POLLING_INTERVAL); + } /* while (1) */ + + return count; +} + +/** + * parport_ip32_fwp_wait_interrupt - wait for FIFO to empty (interrupt-driven) + * @p: pointer to &struct parport + * + * Returns the number of bytes that can safely be written in the FIFO. A + * return value of zero means that the calling function should terminate as + * fast as possible. + */ +static inline unsigned int parport_ip32_fwp_wait_interrupt(struct parport *p) +{ + static unsigned int lost_interrupt = 0; + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport * const physport = p->physport; + DEFINE_TIMER(timer, parport_ip32_timeout, 0, (unsigned long)p); + unsigned long nfault_timeout; + unsigned long expire; + unsigned int count; + unsigned int ecr; + + nfault_timeout = min((unsigned long)physport->cad->timeout, + msecs_to_jiffies(FIFO_NFAULT_TIMEOUT)); + expire = jiffies + physport->cad->timeout; + count = 0; + while (1) { + if (parport_ip32_fifo_wait_break(p, expire)) + break; + + /* Initialize mutex used to take interrupts into account */ + INIT_COMPLETION(priv->irq_complete); + + /* Enable serviceIntr */ + parport_ip32_frob_econtrol(p, ECR_SERVINTR, 0); + + /* Enabling serviceIntr while the FIFO is empty does not + * always generate an interrupt, so check for emptiness + * now. */ + ecr = parport_ip32_read_econtrol(p); + if (!(ecr & ECR_F_EMPTY)) { + /* FIFO is not empty: wait for an interrupt or a + * timeout to occur */ + mod_timer(&timer, jiffies + nfault_timeout); + wait_for_completion(&priv->irq_complete); + del_timer(&timer); + ecr = parport_ip32_read_econtrol(p); + if ((ecr & ECR_F_EMPTY) && !(ecr & ECR_SERVINTR) + && !lost_interrupt) { + printk(KERN_WARNING PPIP32 + "%s: lost interrupt in %s\n", + p->name, __func__); + lost_interrupt = 1; + } + } + + /* Disable serviceIntr */ + parport_ip32_frob_econtrol(p, ECR_SERVINTR, ECR_SERVINTR); + + /* Check FIFO state */ + if (ecr & ECR_F_EMPTY) { + /* FIFO is empty, fill it up */ + count = priv->fifo_depth; + break; + } else if (ecr & ECR_SERVINTR) { + /* FIFO is not empty, but we know that can safely push + * writeIntrThreshold bytes into it */ + count = priv->writeIntrThreshold; + break; + } + /* FIFO is not empty, and we did not get any interrupt. + * Either it's time to check for nFault, or a signal is + * pending. This is verified in + * parport_ip32_fifo_wait_break(), so we continue the loop. */ + } /* while (1) */ + + return count; +} + +/** + * parport_ip32_fifo_write_block_pio - write a block of data (PIO mode) + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * + * Uses PIO to write the contents of the buffer @buf into the parallel port + * FIFO. Returns the number of bytes that were actually written. It can work + * with or without the help of interrupts. The parallel port must be + * correctly initialized before calling parport_ip32_fifo_write_block_pio(). + */ +static size_t parport_ip32_fifo_write_block_pio(struct parport *p, + const void *buf, size_t len) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + const u8 *bufp = buf; + size_t left = len; + + priv->irq_mode = PARPORT_IP32_IRQ_HERE; + + while (left > 0) { + unsigned int count; + + count = (p->irq == PARPORT_IRQ_NONE)? + parport_ip32_fwp_wait_polling(p): + parport_ip32_fwp_wait_interrupt(p); + if (count == 0) { + /* Transmission should be stopped */ + break; + } + if (count > left) { + count = left; + } + if (count == 1) { + parport_ip32_out(*bufp, priv->regs.fifo); + bufp++, left--; + } else { + parport_ip32_out_rep(priv->regs.fifo, bufp, count); + bufp += count, left -= count; + } + } + + priv->irq_mode = PARPORT_IP32_IRQ_FWD; + + return (len - left); +} + +/** + * parport_ip32_fifo_write_block_dma - write a block of data (DMA mode) + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * + * Uses DMA to write the contents of the buffer @buf into the parallel port + * FIFO. Returns the number of bytes that were actually written. The + * parallel port must be correctly initialized before calling + * parport_ip32_fifo_write_block_dma(). + */ +static size_t parport_ip32_fifo_write_block_dma(struct parport *p, + const void *buf, size_t len) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport * const physport = p->physport; + DEFINE_TIMER(timer, parport_ip32_timeout, 0, (unsigned long)p); + unsigned long nfault_timeout; + unsigned long expire; + size_t written; + unsigned int ecr; + + priv->irq_mode = PARPORT_IP32_IRQ_HERE; + + parport_ip32_dma_start(DMA_TO_DEVICE, (void *)buf, len); + INIT_COMPLETION(priv->irq_complete); + parport_ip32_frob_econtrol(p, ECR_DMAEN | ECR_SERVINTR, ECR_DMAEN); + + nfault_timeout = min((unsigned long)physport->cad->timeout, + msecs_to_jiffies(FIFO_NFAULT_TIMEOUT)); + expire = jiffies + physport->cad->timeout; + while (1) { + if (parport_ip32_fifo_wait_break(p, expire)) + break; + + mod_timer(&timer, jiffies + nfault_timeout); + wait_for_completion(&priv->irq_complete); + del_timer(&timer); + ecr = parport_ip32_read_econtrol(p); + if (ecr & ECR_SERVINTR) { + /* DMA transfer just finished */ + break; + } + } + parport_ip32_dma_stop(); + written = len - parport_ip32_dma_get_residue(); + + priv->irq_mode = PARPORT_IP32_IRQ_FWD; + + return written; +} + +/** + * parport_ip32_fifo_write_block - write a block of data + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * + * Uses PIO or DMA to write the contents of the buffer @buf into the parallel + * p FIFO. Returns the number of bytes that were actually written. + */ +static size_t parport_ip32_fifo_write_block(struct parport *p, + const void *buf, size_t len) +{ + size_t written = 0; + if (len) { + /* FIXME - Maybe some threshold value should be set for @len + * under which we revert to PIO mode? */ + written = (p->modes & PARPORT_MODE_DMA)? + parport_ip32_fifo_write_block_dma(p, buf, len): + parport_ip32_fifo_write_block_pio(p, buf, len); + } + return written; +} + +/** + * parport_ip32_drain_fifo - wait for FIFO to empty + * @p: pointer to &struct parport + * @timeout: timeout, in jiffies + * + * This function waits for FIFO to empty. It returns 1 when FIFO is empty, or + * 0 if the timeout @timeout is reached before, or if a signal is pending. + */ +static unsigned int parport_ip32_drain_fifo(struct parport *p, + unsigned long timeout) +{ + unsigned long expire = jiffies + timeout; + unsigned int polling_interval; + unsigned int counter; + + /* Busy wait for approx. 200us */ + for (counter = 0; counter < 40; counter++) { + if (parport_ip32_read_econtrol(p) & ECR_F_EMPTY) + break; + if (time_after(jiffies, expire)) + break; + if (signal_pending(current)) + break; + udelay(5); + } + /* Poll slowly. Polling interval starts with 1 millisecond, and is + * increased exponentially until 128. */ + polling_interval = 1; /* msecs */ + while (!(parport_ip32_read_econtrol(p) & ECR_F_EMPTY)) { + if (time_after_eq(jiffies, expire)) + break; + msleep_interruptible(polling_interval); + if (signal_pending(current)) + break; + if (polling_interval < 128) { + polling_interval *= 2; + } + } + + return !!(parport_ip32_read_econtrol(p) & ECR_F_EMPTY); +} + +/** + * parport_ip32_get_fifo_residue - reset FIFO + * @p: pointer to &struct parport + * @mode: current operation mode (ECR_MODE_PPF or ECR_MODE_ECP) + * + * This function resets FIFO, and returns the number of bytes remaining in it. + */ +static unsigned int parport_ip32_get_fifo_residue(struct parport *p, + unsigned int mode) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + unsigned int residue; + unsigned int cnfga; + + /* FIXME - We are missing one byte if the printer is off-line. I + * don't know how to detect this. It looks that the full bit is not + * always reliable. For the moment, the problem is avoided in most + * cases by testing for BUSY in parport_ip32_compat_write_data(). + */ + if (parport_ip32_read_econtrol(p) & ECR_F_EMPTY) { + residue = 0; + } else { + printk(KERN_DEBUG PPIP32 "%s: FIFO is stuck\n", p->name); + + /* Stop all transfers. + * + * Microsoft's document instructs to drive DCR_STROBE to 0, + * but it doesn't work (at least in Compatibility mode, not + * tested in ECP mode). Switching directly to Test mode (as + * in parport_pc) is not an option: it does confuse the port, + * ECP service interrupts are no more working after that. A + * hard reset is then needed to revert to a sane state. + * + * Let's hope that the FIFO is really stuck and that the + * peripheral doesn't wake up now. + */ + parport_ip32_frob_control(p, DCR_STROBE, 0); + + /* Fill up FIFO */ + for (residue = priv->fifo_depth; residue > 0; residue--) { + if (parport_ip32_read_econtrol(p) & ECR_F_FULL) + break; + parport_ip32_out(0x00, priv->regs.fifo); + } + } + if (residue) { + pr_debug1(PPIP32 "%s: %d PWord%s left in FIFO\n", + p->name, residue, + (residue == 1)? " was": "s were"); + } + + /* Now reset the FIFO */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + + /* Host recovery for ECP mode */ + if (mode == ECR_MODE_ECP) { + parport_ip32_data_reverse(p); + parport_ip32_frob_control(p, DCR_nINIT, 0); + if (parport_wait_peripheral(p, DSR_PERROR, 0)) { + pr_debug1(PPIP32 "%s: PEerror timeout 1 in %s\n", + p->name, __func__); + } + parport_ip32_frob_control(p, DCR_STROBE, DCR_STROBE); + parport_ip32_frob_control(p, DCR_nINIT, DCR_nINIT); + if (parport_wait_peripheral(p, DSR_PERROR, DSR_PERROR)) { + pr_debug1(PPIP32 "%s: PEerror timeout 2 in %s\n", + p->name, __func__); + } + } + + /* Adjust residue if needed */ + parport_ip32_set_mode(p, ECR_MODE_CFG); + cnfga = parport_ip32_in(priv->regs.cnfgA); + if (!(cnfga & CNFGA_nBYTEINTRANS)) { + pr_debug1(PPIP32 "%s: cnfgA contains 0x%02x\n", + p->name, cnfga); + pr_debug1(PPIP32 "%s: Accounting for extra byte\n", + p->name); + residue++; + } + + /* Don't care about partial PWords since we do not support + * PWord != 1 byte. */ + + /* Back to forward PS2 mode. */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + parport_ip32_data_forward(p); + + return residue; +} + +/** + * parport_ip32_compat_write_data - write a block of data in SPP mode + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * @flags: ignored + */ +static size_t parport_ip32_compat_write_data(struct parport *p, + const void *buf, size_t len, + int flags) +{ + static unsigned int ready_before = 1; + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport * const physport = p->physport; + size_t written = 0; + + /* Special case: a timeout of zero means we cannot call schedule(). + * Also if O_NONBLOCK is set then use the default implementation. */ + if (physport->cad->timeout <= PARPORT_INACTIVITY_O_NONBLOCK) { + return parport_ieee1284_write_compat(p, buf, len, flags); + } + + /* Reset FIFO, go in forward mode, and disable ackIntEn */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + parport_ip32_write_control(p, DCR_SELECT | DCR_nINIT); + parport_ip32_data_forward(p); + parport_ip32_disable_irq(p); + parport_ip32_set_mode(p, ECR_MODE_PPF); + physport->ieee1284.phase = IEEE1284_PH_FWD_DATA; + + /* Wait for peripheral to become ready */ + if (parport_wait_peripheral(p, DSR_nBUSY | DSR_nFAULT, + DSR_nBUSY | DSR_nFAULT)) { + /* Avoid to flood the logs */ + if (ready_before) { + printk(KERN_DEBUG PPIP32 "%s: not ready in %s\n", + p->name, __func__); + } + ready_before = 0; + goto stop; + } + ready_before = 1; + + written = parport_ip32_fifo_write_block(p, buf, len); + + /* Wait FIFO to empty. Timeout is proportional to FIFO_depth. */ + parport_ip32_drain_fifo(p, physport->cad->timeout * priv->fifo_depth); + + /* Check for a potential residue */ + written -= parport_ip32_get_fifo_residue(p, ECR_MODE_PPF); + + /* Then, wait for BUSY to get low. */ + if (parport_wait_peripheral(p, DSR_nBUSY, DSR_nBUSY)) { + printk(KERN_DEBUG PPIP32 "%s: BUSY timeout in %s\n", + p->name, __func__); + } + +stop: + /* Reset FIFO */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + physport->ieee1284.phase = IEEE1284_PH_FWD_IDLE; + + return written; +} + +/* + * FIXME - Insert here parport_ip32_ecp_read_data(). + */ + +/** + * parport_ip32_ecp_write_data - write a block of data in ECP mode + * @p: pointer to &struct parport + * @buf: buffer of data to write + * @len: length of buffer @buf + * @flags: ignored + */ +static size_t parport_ip32_ecp_write_data(struct parport *p, + const void *buf, size_t len, + int flags) +{ + static unsigned int ready_before = 1; + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport * const physport = p->physport; + size_t written = 0; + + /* Special case: a timeout of zero means we cannot call schedule(). + * Also if O_NONBLOCK is set then use the default implementation. */ + if (physport->cad->timeout <= PARPORT_INACTIVITY_O_NONBLOCK) { + return parport_ieee1284_ecp_write_data(p, buf, len, flags); + } + + /* Negotiate to forward mode if necessary. */ + if (physport->ieee1284.phase != IEEE1284_PH_FWD_IDLE) { + /* Event 47: Set nInit high. */ + parport_ip32_frob_control(p, DCR_nINIT | DCR_AUTOFD, + DCR_nINIT | DCR_AUTOFD); + + /* Event 49: PError goes high. */ + if (parport_wait_peripheral (p, DSR_PERROR, DSR_PERROR)) { + printk (KERN_DEBUG PPIP32 "%s: PError timeout in %s", + p->name, __func__); + physport->ieee1284.phase = IEEE1284_PH_ECP_DIR_UNKNOWN; + return 0; + } + } + + /* Reset FIFO, go in forward mode, and disable ackIntEn */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + parport_ip32_write_control(p, DCR_SELECT | DCR_nINIT); + parport_ip32_data_forward(p); + parport_ip32_disable_irq(p); + parport_ip32_set_mode(p, ECR_MODE_ECP); + physport->ieee1284.phase = IEEE1284_PH_FWD_DATA; + + /* Wait for peripheral to become ready */ + if (parport_wait_peripheral(p, DSR_nBUSY | DSR_nFAULT, + DSR_nBUSY | DSR_nFAULT)) { + /* Avoid to flood the logs */ + if (ready_before) { + printk(KERN_INFO PPIP32 "%s: not ready in %s\n", + p->name, __func__); + } + ready_before = 0; + goto stop; + } + ready_before = 1; + + written = parport_ip32_fifo_write_block(p, buf, len); + + /* Wait FIFO to empty. Timeout is proportional to FIFO_depth. */ + parport_ip32_drain_fifo(p, physport->cad->timeout * priv->fifo_depth); + + /* Check for a potential residue */ + written -= parport_ip32_get_fifo_residue(p, ECR_MODE_ECP); + + /* Then, wait for BUSY to get low. */ + if (parport_wait_peripheral(p, DSR_nBUSY, DSR_nBUSY)) { + printk(KERN_DEBUG PPIP32 "%s: BUSY timeout in %s\n", + p->name, __func__); + } + +stop: + /* Reset FIFO */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + physport->ieee1284.phase = IEEE1284_PH_FWD_IDLE; + + return written; +} + +/* + * FIXME - Insert here parport_ip32_ecp_write_addr(). + */ + +/*--- Default parport operations ---------------------------------------*/ + +static __initdata struct parport_operations parport_ip32_ops = { + .write_data = parport_ip32_write_data, + .read_data = parport_ip32_read_data, + + .write_control = parport_ip32_write_control, + .read_control = parport_ip32_read_control, + .frob_control = parport_ip32_frob_control, + + .read_status = parport_ip32_read_status, + + .enable_irq = parport_ip32_enable_irq, + .disable_irq = parport_ip32_disable_irq, + + .data_forward = parport_ip32_data_forward, + .data_reverse = parport_ip32_data_reverse, + + .init_state = parport_ip32_init_state, + .save_state = parport_ip32_save_state, + .restore_state = parport_ip32_restore_state, + + .epp_write_data = parport_ieee1284_epp_write_data, + .epp_read_data = parport_ieee1284_epp_read_data, + .epp_write_addr = parport_ieee1284_epp_write_addr, + .epp_read_addr = parport_ieee1284_epp_read_addr, + + .ecp_write_data = parport_ieee1284_ecp_write_data, + .ecp_read_data = parport_ieee1284_ecp_read_data, + .ecp_write_addr = parport_ieee1284_ecp_write_addr, + + .compat_write_data = parport_ieee1284_write_compat, + .nibble_read_data = parport_ieee1284_read_nibble, + .byte_read_data = parport_ieee1284_read_byte, + + .owner = THIS_MODULE, +}; + +/*--- Device detection -------------------------------------------------*/ + +/** + * parport_ip32_ecp_supported - check for an ECP port + * @p: pointer to the &parport structure + * + * Returns 1 if an ECP port is found, and 0 otherwise. This function actually + * checks if an Extended Control Register seems to be present. On successful + * return, the port is placed in SPP mode. + * + * We first check to see if ECR is the same as DCR. If not, the low two bits + * of ECR aren't writable, so we check by writing ECR and reading it back to + * see if it's what we expect. + */ +static __init unsigned int parport_ip32_ecp_supported(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + unsigned int dcr, ecr, mask; + + parport_ip32_out(DCR_SELECT | DCR_nINIT, priv->regs.dcr); + dcr = parport_ip32_in(priv->regs.dcr); + mask = ECR_F_FULL | ECR_F_EMPTY; + if ((parport_ip32_in(priv->regs.ecr) & mask) == (dcr & mask)) { + /* Toggle bit ECR_F_FULL */ + mask = ECR_F_FULL; + parport_ip32_out(dcr ^ mask, priv->regs.dcr); + dcr = parport_ip32_in(priv->regs.dcr); + if ((parport_ip32_in(priv->regs.ecr) & mask) == (dcr & mask)) + goto fail; /* Sure that no ECR register exists */ + } + + ecr = parport_ip32_in(priv->regs.ecr) & (ECR_F_FULL | ECR_F_EMPTY); + if (ecr != ECR_F_EMPTY) + goto fail; + + ecr = ECR_MODE_PS2 | ECR_nERRINTR | ECR_SERVINTR; + parport_ip32_out(ecr, priv->regs.ecr); + if (parport_ip32_in(priv->regs.ecr) != (ecr | ECR_F_EMPTY)) + goto fail; + + pr_probe(p, "Found working ECR register\n"); + parport_ip32_set_mode(p, ECR_MODE_SPP); + parport_ip32_write_control(p, DCR_SELECT | DCR_nINIT); + return 1; + +fail: + pr_probe(p, "ECR register not found\n"); + return 0; +} + +/** + * parport_ip32_fifo_supported - check for FIFO parameters + * @p: pointer to the &parport structure + * + * Check for FIFO parameters of an Extended Capabilities Port. Returns 1 on + * success, and 0 otherwise. Adjust FIFO parameters in the parport structure. + * On return, the port is placed in SPP mode. + */ +static __init unsigned int parport_ip32_fifo_supported(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + unsigned int configa, configb; + unsigned int pword; + unsigned int i; + + /* Configuration mode */ + parport_ip32_set_mode(p, ECR_MODE_CFG); + configa = parport_ip32_in(priv->regs.cnfgA); + configb = parport_ip32_in(priv->regs.cnfgB); + + /* Find out PWord size */ + switch (configa & CNFGA_ID_MASK) { + case CNFGA_ID_8: pword = 1; break; + case CNFGA_ID_16: pword = 2; break; + case CNFGA_ID_32: pword = 4; break; + default: + pr_probe(p, "Unknown implementation ID: 0x%0x\n", + (configa & CNFGA_ID_MASK) >> CNFGA_ID_SHIFT); + goto fail; + break; + } + if (pword != 1) { + pr_probe(p, "Unsupported PWord size: %u\n", pword); + goto fail; + } + priv->pword = pword; + pr_probe(p, "PWord is %u bits\n", 8 * priv->pword); + + /* Check for compression support */ + parport_ip32_out(configb | CNFGB_COMPRESS, priv->regs.cnfgB); + if (parport_ip32_in(priv->regs.cnfgB) & CNFGB_COMPRESS) { + pr_probe(p, "Hardware compression detected (unsupported)\n"); + } + parport_ip32_out(configb & ~CNFGB_COMPRESS, priv->regs.cnfgB); + + /* Reset FIFO and go in test mode (no interrupt, no DMA) */ + parport_ip32_set_mode(p, ECR_MODE_TST); + + /* FIFO must be empty now */ + if (!(parport_ip32_in(priv->regs.ecr) & ECR_F_EMPTY)) { + pr_probe(p, "FIFO not reset\n"); + goto fail; + } + + /* Find out FIFO depth. */ + priv->fifo_depth = 0; + for (i = 0; i < 1024; i++) { + if (parport_ip32_in(priv->regs.ecr) & ECR_F_FULL) { + /* FIFO full */ + priv->fifo_depth = i; + break; + } + parport_ip32_out((u8)i, priv->regs.fifo); + } + if (i >= 1024) { + pr_probe(p, "Can't fill FIFO\n"); + goto fail; + } + if (!priv->fifo_depth) { + pr_probe(p, "Can't get FIFO depth\n"); + goto fail; + } + pr_probe(p, "FIFO is %u PWords deep\n", priv->fifo_depth); + + /* Enable interrupts */ + parport_ip32_frob_econtrol(p, ECR_SERVINTR, 0); + + /* Find out writeIntrThreshold: number of PWords we know we can write + * if we get an interrupt. */ + priv->writeIntrThreshold = 0; + for (i = 0; i < priv->fifo_depth; i++) { + if (parport_ip32_in(priv->regs.fifo) != (u8)i) { + pr_probe(p, "Invalid data in FIFO\n"); + goto fail; + } + if (!priv->writeIntrThreshold + && parport_ip32_in(priv->regs.ecr) & ECR_SERVINTR) { + /* writeIntrThreshold reached */ + priv->writeIntrThreshold = i + 1; + } + if (i + 1 < priv->fifo_depth + && parport_ip32_in(priv->regs.ecr) & ECR_F_EMPTY) { + /* FIFO empty before the last byte? */ + pr_probe(p, "Data lost in FIFO\n"); + goto fail; + } + } + if (!priv->writeIntrThreshold) { + pr_probe(p, "Can't get writeIntrThreshold\n"); + goto fail; + } + pr_probe(p, "writeIntrThreshold is %u\n", priv->writeIntrThreshold); + + /* FIFO must be empty now */ + if (!(parport_ip32_in(priv->regs.ecr) & ECR_F_EMPTY)) { + pr_probe(p, "Can't empty FIFO\n"); + goto fail; + } + + /* Reset FIFO */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + /* Set reverse direction (must be in PS2 mode) */ + parport_ip32_data_reverse(p); + /* Test FIFO, no interrupt, no DMA */ + parport_ip32_set_mode(p, ECR_MODE_TST); + /* Enable interrupts */ + parport_ip32_frob_econtrol(p, ECR_SERVINTR, 0); + + /* Find out readIntrThreshold: number of PWords we can read if we get + * an interrupt. */ + priv->readIntrThreshold = 0; + for (i = 0; i < priv->fifo_depth; i++) { + parport_ip32_out(0xaa, priv->regs.fifo); + if (!priv->readIntrThreshold + && parport_ip32_in(priv->regs.ecr) & ECR_SERVINTR) { + /* readIntrThreshold reached */ + priv->readIntrThreshold = i + 1; + } + } + if (!priv->readIntrThreshold) { + pr_probe(p, "Can't get readIntrThreshold\n"); + goto fail; + } + pr_probe(p, "readIntrThreshold is %u\n", priv->readIntrThreshold); + + /* Reset ECR */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + parport_ip32_data_forward(p); + parport_ip32_set_mode(p, ECR_MODE_SPP); + return 1; + +fail: + priv->fifo_depth = 0; + parport_ip32_set_mode(p, ECR_MODE_SPP); + return 0; +} + +/*--- Initialization code ----------------------------------------------*/ + +/** + * parport_ip32_make_isa_registers - compute (ISA) register addresses + * @regs: pointer to &struct parport_ip32_regs to fill + * @base: base address of standard and EPP registers + * @base_hi: base address of ECP registers + * @regshift: how much to shift register offset by + * + * Compute register addresses, according to the ISA standard. The addresses + * of the standard and EPP registers are computed from address @base. The + * addresses of the ECP registers are computed from address @base_hi. + */ +static void __init +parport_ip32_make_isa_registers(struct parport_ip32_regs *regs, + void __iomem *base, void __iomem *base_hi, + unsigned int regshift) +{ +#define r_base(offset) ((u8 __iomem *)base + ((offset) << regshift)) +#define r_base_hi(offset) ((u8 __iomem *)base_hi + ((offset) << regshift)) + *regs = (struct parport_ip32_regs){ + .data = r_base(0), + .dsr = r_base(1), + .dcr = r_base(2), + .eppAddr = r_base(3), + .eppData0 = r_base(4), + .eppData1 = r_base(5), + .eppData2 = r_base(6), + .eppData3 = r_base(7), + .ecpAFifo = r_base(0), + .fifo = r_base_hi(0), + .cnfgA = r_base_hi(0), + .cnfgB = r_base_hi(1), + .ecr = r_base_hi(2) + }; +#undef r_base_hi +#undef r_base +} + +/** + * parport_ip32_probe_port - probe and register IP32 built-in parallel port + * + * Returns the new allocated &parport structure. On error, an error code is + * encoded in return value with the ERR_PTR function. + */ +static __init struct parport *parport_ip32_probe_port(void) +{ + struct parport_ip32_regs regs; + struct parport_ip32_private *priv = NULL; + struct parport_operations *ops = NULL; + struct parport *p = NULL; + int err; + + parport_ip32_make_isa_registers(®s, &mace->isa.parallel, + &mace->isa.ecp1284, 8 /* regshift */); + + ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL); + priv = kmalloc(sizeof(struct parport_ip32_private), GFP_KERNEL); + p = parport_register_port(0, PARPORT_IRQ_NONE, PARPORT_DMA_NONE, ops); + if (ops == NULL || priv == NULL || p == NULL) { + err = -ENOMEM; + goto fail; + } + p->base = MACE_BASE + offsetof(struct sgi_mace, isa.parallel); + p->base_hi = MACE_BASE + offsetof(struct sgi_mace, isa.ecp1284); + p->private_data = priv; + + *ops = parport_ip32_ops; + *priv = (struct parport_ip32_private){ + .regs = regs, + .dcr_writable = DCR_DIR | DCR_SELECT | DCR_nINIT | + DCR_AUTOFD | DCR_STROBE, + .irq_mode = PARPORT_IP32_IRQ_FWD, + }; + init_completion(&priv->irq_complete); + + /* Probe port. */ + if (!parport_ip32_ecp_supported(p)) { + err = -ENODEV; + goto fail; + } + parport_ip32_dump_state (p, "begin init", 0); + + /* We found what looks like a working ECR register. Simply assume + * that all modes are correctly supported. Enable basic modes. */ + p->modes = PARPORT_MODE_PCSPP | PARPORT_MODE_SAFEININT; + p->modes |= PARPORT_MODE_TRISTATE; + + if (!parport_ip32_fifo_supported(p)) { + printk(KERN_WARNING PPIP32 + "%s: error: FIFO disabled\n", p->name); + /* Disable hardware modes depending on a working FIFO. */ + features &= ~PARPORT_IP32_ENABLE_SPP; + features &= ~PARPORT_IP32_ENABLE_ECP; + /* DMA is not needed if FIFO is not supported. */ + features &= ~PARPORT_IP32_ENABLE_DMA; + } + + /* Request IRQ */ + if (features & PARPORT_IP32_ENABLE_IRQ) { + int irq = MACEISA_PARALLEL_IRQ; + if (request_irq(irq, parport_ip32_interrupt, 0, p->name, p)) { + printk(KERN_WARNING PPIP32 + "%s: error: IRQ disabled\n", p->name); + /* DMA cannot work without interrupts. */ + features &= ~PARPORT_IP32_ENABLE_DMA; + } else { + pr_probe(p, "Interrupt support enabled\n"); + p->irq = irq; + priv->dcr_writable |= DCR_IRQ; + } + } + + /* Allocate DMA resources */ + if (features & PARPORT_IP32_ENABLE_DMA) { + if (parport_ip32_dma_register()) { + printk(KERN_WARNING PPIP32 + "%s: error: DMA disabled\n", p->name); + } else { + pr_probe(p, "DMA support enabled\n"); + p->dma = 0; /* arbitrary value != PARPORT_DMA_NONE */ + p->modes |= PARPORT_MODE_DMA; + } + } + + if (features & PARPORT_IP32_ENABLE_SPP) { + /* Enable compatibility FIFO mode */ + p->ops->compat_write_data = parport_ip32_compat_write_data; + p->modes |= PARPORT_MODE_COMPAT; + pr_probe(p, "Hardware support for SPP mode enabled\n"); + } + if (features & PARPORT_IP32_ENABLE_EPP) { + /* Set up access functions to use EPP hardware. */ + p->ops->epp_read_data = parport_ip32_epp_read_data; + p->ops->epp_write_data = parport_ip32_epp_write_data; + p->ops->epp_read_addr = parport_ip32_epp_read_addr; + p->ops->epp_write_addr = parport_ip32_epp_write_addr; + p->modes |= PARPORT_MODE_EPP; + pr_probe(p, "Hardware support for EPP mode enabled\n"); + } + if (features & PARPORT_IP32_ENABLE_ECP) { + /* Enable ECP FIFO mode */ + p->ops->ecp_write_data = parport_ip32_ecp_write_data; + /* FIXME - not implemented */ +/* p->ops->ecp_read_data = parport_ip32_ecp_read_data; */ +/* p->ops->ecp_write_addr = parport_ip32_ecp_write_addr; */ + p->modes |= PARPORT_MODE_ECP; + pr_probe(p, "Hardware support for ECP mode enabled\n"); + } + + /* Initialize the port with sensible values */ + parport_ip32_set_mode(p, ECR_MODE_PS2); + parport_ip32_write_control(p, DCR_SELECT | DCR_nINIT); + parport_ip32_data_forward(p); + parport_ip32_disable_irq(p); + parport_ip32_write_data(p, 0x00); + parport_ip32_dump_state (p, "end init", 0); + + /* Print out what we found */ + printk(KERN_INFO "%s: SGI IP32 at 0x%lx (0x%lx)", + p->name, p->base, p->base_hi); + if (p->irq != PARPORT_IRQ_NONE) { + printk(", irq %d", p->irq); + } + printk(" ["); +#define printmode(x) if (p->modes & PARPORT_MODE_##x) \ + printk("%s%s", f++? ",": "", #x) + { + unsigned int f = 0; + printmode(PCSPP); + printmode(TRISTATE); + printmode(COMPAT); + printmode(EPP); + printmode(ECP); + printmode(DMA); + } +#undef printmode + printk("]\n"); + + parport_announce_port(p); + return p; + +fail: + if (p) { + parport_put_port(p); + } + kfree(priv); + kfree(ops); + return ERR_PTR(err); +} + +/** + * parport_ip32_unregister_port - unregister a parallel port + * @p: pointer to the &struct parport + * + * Unregisters a parallel port and free previously allocated resources + * (memory, IRQ, ...). + */ +static __exit void parport_ip32_unregister_port(struct parport *p) +{ + struct parport_ip32_private * const priv = p->physport->private_data; + struct parport_operations *ops = p->ops; + + parport_remove_port(p); + if (p->modes & PARPORT_MODE_DMA) + parport_ip32_dma_unregister(); + if (p->irq != PARPORT_IRQ_NONE) + free_irq(p->irq, p); + parport_put_port(p); + kfree(priv); + kfree(ops); +} + +/** + * parport_ip32_init - module initialization function + */ +static int __init parport_ip32_init(void) +{ + pr_info(PPIP32 "SGI IP32 built-in parallel port driver v0.4\n"); + pr_debug1(PPIP32 "Compiled on %s, %s\n", __DATE__, __TIME__); + this_port = parport_ip32_probe_port(); + return IS_ERR(this_port)? PTR_ERR(this_port): 0; +} + +/** + * parport_ip32_exit - module termination function + */ +static void __exit parport_ip32_exit(void) +{ + parport_ip32_unregister_port(this_port); +} + +/*--- Module stuff -----------------------------------------------------*/ + +MODULE_AUTHOR("Arnaud Giersch "); +MODULE_DESCRIPTION("SGI IP32 built-in parallel port driver"); +MODULE_LICENSE("GPL"); +MODULE_VERSION("0.4"); /* update in parport_ip32_init() too */ + +module_init(parport_ip32_init); +module_exit(parport_ip32_exit); + +module_param(verbose_probing, bool, S_IRUGO); +MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialization"); + +module_param(features, uint, S_IRUGO); +MODULE_PARM_DESC(features, + "Bit mask of features to enable" + ", bit 0: IRQ support" + ", bit 1: DMA support" + ", bit 2: hardware SPP mode" + ", bit 3: hardware EPP mode" + ", bit 4: hardware ECP mode"); + +/*--- Inform (X)Emacs about preferred coding style ---------------------*/ +/* + * Local Variables: + * mode: c + * c-file-style: "linux" + * indent-tabs-mode: t + * tab-width: 8 + * fill-column: 78 + * ispell-local-dictionary: "american" + * End: + */ diff -Naurp linux-2.6.15-rc2.old/include/linux/parport.h linux-2.6.15-rc2/include/linux/parport.h --- linux-2.6.15-rc2.old/include/linux/parport.h 2005-11-20 04:25:03.000000000 +0100 +++ linux-2.6.15-rc2/include/linux/parport.h 2005-11-20 15:04:17.000000000 +0100 @@ -128,6 +128,11 @@ struct amiga_parport_state { unsigned char statusdir;/* ciab.ddrb & 7 */ }; +struct ip32_parport_state { + unsigned int dcr; + unsigned int ecr; +}; + struct parport_state { union { struct pc_parport_state pc; @@ -135,6 +140,7 @@ struct parport_state { struct ax_parport_state ax; struct amiga_parport_state amiga; /* Atari has not state. */ + struct ip32_parport_state ip32; void *misc; } u; }; From Brian.Knittel@powertv.com Tue Nov 22 02:56:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 02:57:09 +0000 (GMT) Received: from mask.powertv.com ([12.146.136.163]:59074 "EHLO hqmail01.powertv.com") by ftp.linux-mips.org with ESMTP id S8134241AbVKVC4u (ORCPT ); Tue, 22 Nov 2005 02:56:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: Saving arguments on the stack Date: Mon, 21 Nov 2005 18:59:20 -0800 Message-ID: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the state of KDB on MIPS? Thread-Index: AcWnfgzdE/lW8rVCT/m95+wNPa/iERHkkdY5 From: "Knittel, Brian" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Brian.Knittel@powertv.com Precedence: bulk X-list: linux-mips Content-Length: 337 Lines: 5 SGksDQoNCkknZCBsaWtlIHRvIGZvcmNlIHRoZSBjb21waWxlciB0byBzdG9yZSBhcmd1bWVudHMg b24gdGhlIHN0YWNrIHdpdGggb3RoZXJ3aXNlIG9wdGltaXplZCBjb2RlLg0KDQpJIGZvdW5kIGEg cmVmZXJuY2UgaW4gdGhlIGFyY2hpdmVzIChmb3JtIDIwMDEpIGZvciB1c2luZyAtMCAobm8gb3B0 aW1pemF0aW9uKS4gSGFzIGFueW9uZSBmb3VuZCBhbm90aGVyIHdheSB0byBkbyB0aGlzPw0KDQpU aGFua3MsDQoNCi0tQnJpYW4NCg0K From kevink@mips.com Tue Nov 22 08:49:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 08:49:51 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:50428 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8134445AbVKVIte (ORCPT ); Tue, 22 Nov 2005 08:49:34 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id jAM8q2sO013138; Tue, 22 Nov 2005 00:52:03 -0800 (PST) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id jAM8q316020211; Tue, 22 Nov 2005 00:52:04 -0800 (PST) Message-ID: <4382DC76.60506@mips.com> Date: Tue, 22 Nov 2005 09:53:10 +0100 From: "Kevin D. Kissell" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Knittel, Brian" CC: linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> In-Reply-To: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Content-Length: 478 Lines: 14 Knittel, Brian wrote: > Hi, > > I'd like to force the compiler to store arguments on the stack with otherwise optimized code. > > I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this? If I recall correctly, if you specify -g to enable debugger support, the subroutine prologues store the arguments into their stack slots, even if a higher level of optimization is otherwise specified. Regards, Kevin K. From nigel@mips.com Tue Nov 22 11:18:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 11:19:13 +0000 (GMT) Received: from alg145.algor.co.uk ([62.254.210.145]:48134 "EHLO dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S3466282AbVKVLS4 (ORCPT ); Tue, 22 Nov 2005 11:18:56 +0000 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 1EeW9T-0007k7-00; Tue, 22 Nov 2005 11:17:31 +0000 Received: from highbury.mips.com ([192.168.192.236]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1EeWD3-0000yF-00; Tue, 22 Nov 2005 11:21:13 +0000 Message-ID: <4382FF29.2020605@mips.com> Date: Tue, 22 Nov 2005 11:21:13 +0000 From: Nigel Stephens Organization: MIPS Technologies User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <4382DC76.60506@mips.com> In-Reply-To: <4382DC76.60506@mips.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.712, required 4, AWL, BAYES_00) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips Content-Length: 735 Lines: 28 Kevin D. Kissell wrote: > Knittel, Brian wrote: > >> Hi, >> >> I'd like to force the compiler to store arguments on the stack with >> otherwise optimized code. >> >> I found a refernce in the archives (form 2001) for using -0 (no >> optimization). Has anyone found another way to do this? > > > If I recall correctly, if you specify -g to enable debugger support, > the subroutine prologues store the arguments into their stack slots, > even if a higher level of optimization is otherwise specified. 'Fraid not: the -g option only adds debug info to the object file, it shouldn't alter the generated code. Using -O0 will certainly store everything on the stack, but it also won't be "with otherwise optimized code". Nigel From ralf@linux-mips.org Tue Nov 22 11:21:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 11:22:05 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:43541 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3466284AbVKVLVr (ORCPT ); Tue, 22 Nov 2005 11:21:47 +0000 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 jAMBOMgb007445; Tue, 22 Nov 2005 11:24:22 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAMBOHnN007444; Tue, 22 Nov 2005 11:24:17 GMT Date: Tue, 22 Nov 2005 11:24:17 +0000 From: Ralf Baechle To: Nigel Stephens Cc: "Kevin D. Kissell" , "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack Message-ID: <20051122112417.GB2706@linux-mips.org> References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <4382DC76.60506@mips.com> <4382FF29.2020605@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4382FF29.2020605@mips.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9530 X-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: 843 Lines: 23 On Tue, Nov 22, 2005 at 11:21:13AM +0000, Nigel Stephens wrote: > >>I'd like to force the compiler to store arguments on the stack with > >>otherwise optimized code. > >> > >>I found a refernce in the archives (form 2001) for using -0 (no > >>optimization). Has anyone found another way to do this? > > > > > >If I recall correctly, if you specify -g to enable debugger support, > >the subroutine prologues store the arguments into their stack slots, > >even if a higher level of optimization is otherwise specified. > > > 'Fraid not: the -g option only adds debug info to the object file, it > shouldn't alter the generated code. Using -O0 will certainly store > everything on the stack, but it also won't be "with otherwise optimized > code". And the kernel won't build without optimization - but that's FAQ since 10 years. Ralf From ralf@linux-mips.org Tue Nov 22 11:35:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 11:35:44 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:25630 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3466285AbVKVLf0 (ORCPT ); Tue, 22 Nov 2005 11:35:26 +0000 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 jAMBc10q007901; Tue, 22 Nov 2005 11:38:01 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAMBc1qf007900; Tue, 22 Nov 2005 11:38:01 GMT Date: Tue, 22 Nov 2005 11:38:01 +0000 From: Ralf Baechle To: "Knittel, Brian" Cc: linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack Message-ID: <20051122113801.GC2706@linux-mips.org> References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9531 X-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: 582 Lines: 14 On Mon, Nov 21, 2005 at 06:59:20PM -0800, Knittel, Brian wrote: > I'd like to force the compiler to store arguments on the stack with otherwise optimized code. > > I found a refernce in the archives (form 2001) for using -0 (no optimization). Has anyone found another way to do this? -O is optimization - same as -O1. Gcc will save all arguments to the stack for variadic functions (like: int printf(const char *fmt, ...)) when using somewhat older compiler - I think before gcc 3.2 or so. Newer compilers will only save argument one and up. Maybe that's good enough? Ralf From macro@linux-mips.org Tue Nov 22 11:36:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 11:37:08 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:5902 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3466285AbVKVLgv (ORCPT ); Tue, 22 Nov 2005 11:36:51 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 44C65F5968; Tue, 22 Nov 2005 12:39:27 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23744-06; Tue, 22 Nov 2005 12:39:27 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 04473E1C84; Tue, 22 Nov 2005 12:39:27 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jAMBdKjL008145; Tue, 22 Nov 2005 12:39:20 +0100 Date: Tue, 22 Nov 2005 11:39:28 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Nigel Stephens , "Kevin D. Kissell" , "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack In-Reply-To: <20051122112417.GB2706@linux-mips.org> Message-ID: References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <4382DC76.60506@mips.com> <4382FF29.2020605@mips.com> <20051122112417.GB2706@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87.1/1183/Tue Nov 22 10:19:57 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9532 X-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: 14 On Tue, 22 Nov 2005, Ralf Baechle wrote: > > 'Fraid not: the -g option only adds debug info to the object file, it > > shouldn't alter the generated code. Using -O0 will certainly store > > everything on the stack, but it also won't be "with otherwise optimized > > code". > > And the kernel won't build without optimization - but that's FAQ since > 10 years. Well, with "__attribute__((always_inline))" available and actually used already, perhaps this requirement could be relaxed nowadays... Maciej From ralf@linux-mips.org Tue Nov 22 12:24:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 12:24:53 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:53532 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S3466290AbVKVMY3 (ORCPT ); Tue, 22 Nov 2005 12:24:29 +0000 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 jAMCR4wk009537; Tue, 22 Nov 2005 12:27:04 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAMCR38u009536; Tue, 22 Nov 2005 12:27:03 GMT Date: Tue, 22 Nov 2005 12:27:03 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Nigel Stephens , "Kevin D. Kissell" , "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack Message-ID: <20051122122703.GD2706@linux-mips.org> References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <4382DC76.60506@mips.com> <4382FF29.2020605@mips.com> <20051122112417.GB2706@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9533 X-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: 940 Lines: 22 On Tue, Nov 22, 2005 at 11:39:28AM +0000, Maciej W. Rozycki wrote: > > > 'Fraid not: the -g option only adds debug info to the object file, it > > > shouldn't alter the generated code. Using -O0 will certainly store > > > everything on the stack, but it also won't be "with otherwise optimized > > > code". > > > > And the kernel won't build without optimization - but that's FAQ since > > 10 years. > > Well, with "__attribute__((always_inline))" available and actually used > already, perhaps this requirement could be relaxed nowadays... There were functions in the network stack that intensionally were declared extern inline to make sure the compiler won't be able to outline that function unnoticed. I just grepped for it and can't find it anymore, must be a relativly recent improvment. We also rely on the compiler eleminating calls to certain functions entirely, for example to __xchg_called_with_bad_pointer(). Ralf From dom@mips.com Tue Nov 22 12:38:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 12:39:05 +0000 (GMT) Received: from alg145.algor.co.uk ([62.254.210.145]:64013 "EHLO dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S3466290AbVKVMir (ORCPT ); Tue, 22 Nov 2005 12:38:47 +0000 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 1EeXOn-0004H3-00; Tue, 22 Nov 2005 12:37:25 +0000 Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1EeXSQ-0003FB-00; Tue, 22 Nov 2005 12:41:11 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17283.4578.898036.622893@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 12:41:06 +0000 To: Ralf Baechle Cc: "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack In-Reply-To: <20051122113801.GC2706@linux-mips.org> References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <20051122113801.GC2706@linux-mips.org> X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.848, required 4, AWL, BAYES_00) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@mips.com Precedence: bulk X-list: linux-mips Content-Length: 267 Lines: 13 Brian, > > I'd like to force the compiler to store arguments on the stack > > with otherwise optimized code. Sounds like you're out of luck. Perhaps you'd do better to go one step back and explain what you're trying to do? -- Dominic Sweetman MIPS Technologies From macro@linux-mips.org Tue Nov 22 14:00:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 14:00:55 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:6662 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S3466297AbVKVOAg (ORCPT ); Tue, 22 Nov 2005 14:00:36 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 70D06E1CB0; Tue, 22 Nov 2005 15:03:12 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13067-03; Tue, 22 Nov 2005 15:03:12 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 2A9B8E1C61; Tue, 22 Nov 2005 15:03:12 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id jAME3AG6020761; Tue, 22 Nov 2005 15:03:12 +0100 Date: Tue, 22 Nov 2005 14:03:12 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Nigel Stephens , "Kevin D. Kissell" , "Knittel, Brian" , linux-mips@linux-mips.org Subject: Re: Saving arguments on the stack In-Reply-To: <20051122122703.GD2706@linux-mips.org> Message-ID: References: <762C0A863A7674478671627FEAF5848105AF92D2@hqmail01.powertv.com> <4382DC76.60506@mips.com> <4382FF29.2020605@mips.com> <20051122112417.GB2706@linux-mips.org> <20051122122703.GD2706@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87.1/1183/Tue Nov 22 10:19:57 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9535 X-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: 699 Lines: 16 On Tue, 22 Nov 2005, Ralf Baechle wrote: > There were functions in the network stack that intensionally were > declared extern inline to make sure the compiler won't be able to outline > that function unnoticed. I just grepped for it and can't find it > anymore, must be a relativly recent improvment. > > We also rely on the compiler eleminating calls to certain functions > entirely, for example to __xchg_called_with_bad_pointer(). Well, that's exactly what "__attribute__((always_inline))" does -- either inline or fail; the latter AFAIK only happening if the function's body is unavailable to the current compilation unit. That happens regardless of any optimization settings. Maciej From Brian.Knittel@powertv.com Tue Nov 22 18:21:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 18:21:52 +0000 (GMT) Received: from mask.powertv.com ([12.146.136.163]:45461 "EHLO hqmail01.powertv.com") by ftp.linux-mips.org with ESMTP id S8134455AbVKVSVf (ORCPT ); Tue, 22 Nov 2005 18:21:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: Saving arguments on the stack Date: Tue, 22 Nov 2005 10:24:09 -0800 Message-ID: <762C0A863A7674478671627FEAF5848105AF92D5@hqmail01.powertv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Saving arguments on the stack Thread-Index: AcXvYhBLECiZIEeYTnaG4w7B0/PbpwALpxeA From: "Knittel, Brian" To: Cc: "Dominic Sweetman" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Brian.Knittel@powertv.com Precedence: bulk X-list: linux-mips Content-Length: 1403 Lines: 19 V2UnZCBsaWtlIHRvIGFkZCBhcmd1bWVudHMgdG8gdGhlIGJhY2t0cmFjZSBpbiBPb3BzIG1lc3Nh Z2VzIHRvIG1ha2UgZGVidWdnaW5nIGZyb20gdGhlc2UgcmVwb3J0cyBtb3JlIGVmZmljaWVudC4g SXQgaXMgcGFydGljdWxhcmx5IHVzZWZ1bCBmb3IgZGV0ZXJtaW5pbmcgd2hlcmUgdGhlIHByb2Js ZW0gd2FzIGdlbmVyYXRlZCwgcGFydGljdWxhcmx5IHdoZW4gYmFkIHBvaW50ZXJzIGFyZSBwYXNz ZWQgaW4uIFRoaXMgaXMgZm9yIHByb2R1Y3Rpb24gZW1iZWRkZWQgZGV2aWNlcyB3aXRoIG9wdGlt aXplZCBjb2RlIGFuZCB3aGljaCByZWJvb3QgaW1tZWRpYXRlbHkgYWZ0ZXIgc3RvcmluZyBvciBz ZW5kaW5nIHRoZSBPb3BzIG1lc3NhZ2UuIFBlcmZvcm1hbmNlIGlzIGFuIGlzc3VlLCBidXQgdGhl IG92ZXJoZWFkIG9mIHN0b3JpbmcgdGhlIGFyZ3VtZW50cyBvbiB0aGUgc3RhY2sgaXMgbGlrZWx5 IHdvcnRoIHRoZSBhZGRlZCBkZWJ1ZyBpbmZvLg0KIA0KVGhhbmtzLA0KLS1Ccmlhbg0KDQoJLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogRG9taW5pYyBTd2VldG1hbiBbbWFpbHRv OmRvbUBtaXBzLmNvbV0gDQoJU2VudDogVHVlIDExLzIyLzIwMDUgNDo0MSBBTSANCglUbzogUmFs ZiBCYWVjaGxlIA0KCUNjOiBLbml0dGVsLCBCcmlhbjsgbGludXgtbWlwc0BsaW51eC1taXBzLm9y ZyANCglTdWJqZWN0OiBSZTogU2F2aW5nIGFyZ3VtZW50cyBvbiB0aGUgc3RhY2sNCgkNCgkNCg0K DQoJQnJpYW4sDQoJDQoJPiA+IEknZCBsaWtlIHRvIGZvcmNlIHRoZSBjb21waWxlciB0byBzdG9y ZSBhcmd1bWVudHMgb24gdGhlIHN0YWNrDQoJPiA+IHdpdGggb3RoZXJ3aXNlIG9wdGltaXplZCBj b2RlLg0KCQ0KCVNvdW5kcyBsaWtlIHlvdSdyZSBvdXQgb2YgbHVjay4gIFBlcmhhcHMgeW91J2Qg ZG8gYmV0dGVyIHRvIGdvIG9uZQ0KCXN0ZXAgYmFjayBhbmQgZXhwbGFpbiB3aGF0IHlvdSdyZSB0 cnlpbmcgdG8gZG8/DQoJDQoJLS0NCglEb21pbmljIFN3ZWV0bWFuDQoJTUlQUyBUZWNobm9sb2dp ZXMNCgkNCgkNCg0K From jcrouse@cosmic.amd.com Tue Nov 22 20:52:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 20:52:25 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:27817 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8134136AbVKVUwG (ORCPT ); Tue, 22 Nov 2005 20:52:06 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAMKsg6l026186; Tue, 22 Nov 2005 14:54:43 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 14:54:27 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAMKsQeP021677; Tue, 22 Nov 2005 14:54:26 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 923D31FF4; Tue, 22 Nov 2005 13:54:26 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAMKxc1c004512; Tue, 22 Nov 2005 13:59:38 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAMKxcSk004511; Tue, 22 Nov 2005 13:59:38 -0700 Date: Tue, 22 Nov 2005 13:59:38 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] Retain the write-only OD from being clobbered Message-ID: <20051122205938.GR18119@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D5A091M8573332-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1346 Lines: 45 First of several patches forwarded to me by Sergei Shtylyov. Ralf, these should be good to go for the tree. Retain the write-only OD bit from being clobbered by coherency_setup() Signed-off-by: Sergei Shtylyov Acked-by: Jordan Crouse --- arch/mips/mm/c-r4k.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index 38223b4..044c468 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -29,6 +29,10 @@ #include #include /* for run_uncached() */ +#ifdef CONFIG_SOC_AU1X00 +#include +#endif + /* * Must die. */ @@ -1203,6 +1207,16 @@ static inline void coherency_setup(void) { change_c0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); +#ifdef CONFIG_SOC_AU1X00 + /* + * c0_config.od (bit 19) is write only (and reads as 0) on many early + * revs of AMD Au1x00 SOCs. It disables the bus transaction overlapping + * and needs to be set to correct the various errata. So if it has been + * set by the board setup code we must leave it set... + */ + if (cur_cpu_spec[0]->cpu_od) + set_c0_config(1 << 19); +#endif /* * c0_status.cu=0 specifies that updates by the sc instruction use * the coherency mode specified by the TLB; 1 means cachable From jcrouse@cosmic.amd.com Tue Nov 22 20:55:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 20:55:36 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:8362 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8134136AbVKVUzS (ORCPT ); Tue, 22 Nov 2005 20:55:18 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAMKvtF2027194; Tue, 22 Nov 2005 14:57:55 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 14:57:46 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAMKvkeP022275; Tue, 22 Nov 2005 14:57:46 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id F0D291FF4; Tue, 22 Nov 2005 13:57:45 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAML2w9T004569; Tue, 22 Nov 2005 14:02:58 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAML2wfP004568; Tue, 22 Nov 2005 14:02:58 -0700 Date: Tue, 22 Nov 2005 14:02:58 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] Fix BSCR accesses Message-ID: <20051122210258.GT18119@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D59C01M8574078-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1067 Lines: 38 Last one from Sergei: Fix BSCR accesses in the board setup code. --- arch/mips/au1000/db1x00/board_setup.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/mips/au1000/db1x00/board_setup.c b/arch/mips/au1000/db1x00/board_setup.c index ac05ba0..f00ec3b 100644 --- a/arch/mips/au1000/db1x00/board_setup.c +++ b/arch/mips/au1000/db1x00/board_setup.c @@ -45,13 +45,12 @@ #include #include -/* not correct for db1550 */ -static BCSR * const bcsr = (BCSR *)0xAE000000; +static BCSR * const bcsr = (BCSR *)BCSR_KSEG1_ADDR; void board_reset (void) { /* Hit BCSR.SYSTEM_CONTROL[SW_RST] */ - au_writel(0x00000000, 0xAE00001C); + bcsr->swreset = 0x0000; } void __init board_setup(void) @@ -75,7 +74,7 @@ void __init board_setup(void) bcsr->resets |= BCSR_RESETS_IRDA_MODE_OFF; au_sync(); #endif - au_writel(0, 0xAE000010); /* turn off pcmcia power */ + bcsr->pcmcia = 0x0000; /* turn off PCMCIA power */ #ifdef CONFIG_MIPS_MIRAGE /* enable GPIO[31:0] inputs */ From jcrouse@cosmic.amd.com Tue Nov 22 20:56:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 20:56:32 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:726 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8134455AbVKVUz7 (ORCPT ); Tue, 22 Nov 2005 20:55:59 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAMKwLfo013592; Tue, 22 Nov 2005 12:58:35 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 12:56:01 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAMKu0Zi010726; Tue, 22 Nov 2005 12:56:00 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 4ECD61FF4; Tue, 22 Nov 2005 13:56:00 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAML1CMG004550; Tue, 22 Nov 2005 14:01:12 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAML1Ce8004549; Tue, 22 Nov 2005 14:01:12 -0700 Date: Tue, 22 Nov 2005 14:01:12 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] Cleanups in au1000/common/time.c Message-ID: <20051122210112.GS18119@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D5A6B2VS8350436-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1191 Lines: 40 More from Sergei. Cleanups in arch/mips/au1000/common/time.c Signed-off-by: Sergei Shtylyov Acked-by: Jordan Crouse --- arch/mips/au1000/common/time.c | 9 ++------- 1 files changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/mips/au1000/common/time.c b/arch/mips/au1000/common/time.c index 883d3f3..fe883d4 100644 --- a/arch/mips/au1000/common/time.c +++ b/arch/mips/au1000/common/time.c @@ -50,10 +50,6 @@ #include #include -extern void do_softirq(void); -extern volatile unsigned long wall_jiffies; -unsigned long missed_heart_beats = 0; - static unsigned long r4k_offset; /* Amount to increment compare reg each time */ static unsigned long r4k_cur; /* What counter should be at next timer irq */ int no_au1xxx_32khz; @@ -387,10 +383,9 @@ static unsigned long do_fast_pm_gettimeo } #endif -void au1xxx_timer_setup(struct irqaction *irq) +void __init au1xxx_timer_setup(struct irqaction *irq) { - unsigned int est_freq; - extern unsigned long (*do_gettimeoffset)(void); + unsigned int est_freq; printk("calculating r4koff... "); r4k_offset = cal_r4koff(); From sshtylyov@ru.mvista.com Tue Nov 22 21:06:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 21:06:25 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:28878 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8134460AbVKVVGG (ORCPT ); Tue, 22 Nov 2005 21:06:06 +0000 Received: (qmail 29247 invoked from network); 22 Nov 2005 21:08:41 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 22 Nov 2005 21:08:41 -0000 Message-ID: <43838957.2020106@ru.mvista.com> Date: Wed, 23 Nov 2005 00:10:47 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: [PATCH] Retain the write-only OD from being clobbered References: <20051122205938.GR18119@cosmic.amd.com> In-Reply-To: <20051122205938.GR18119@cosmic.amd.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1800 Lines: 37 Hello. Jordan Crouse wrote: > First of several patches forwarded to me by Sergei Shtylyov. Ralf, > these should be good to go for the tree. > > Retain the write-only OD bit from being clobbered by coherency_setup() > > Signed-off-by: Sergei Shtylyov > Acked-by: Jordan Crouse A long story of a long standing bug follows... AMD Au1x00 board setup code in au1x00_setup() sets CONFIG.OD bit for the early steppings of the Au1x00 SOCs, consulting the PRID table in arch/mips/au1000/common/cputable.c. This bit disables the bus transaction overlapping which causes a number of errata in those early SOC steppings (including the one that I think we've run into with USB host--at least setting the bit back to 1 fixed it, although disabling USB host DMA coherency also seemd to help). The problem is that this bit is write-only and reads as 0 on almost all SOCs that need it set. So, when the arch/mm/c-r4k.c code does RMW to the CONFIG reg. in coherency_setup(), its value is lost, and the chip again becomes prone to all the nasty errata that it has just been saved from... :-) There's couple more places in the assembly code where the CP0 CONFIG reg. is written without care of OD bit: 1) In the cache parity error handler (arch/mips/mm/cex-gen.S) -- as the panic() call follows shortly, probably CACHE.OD=0 doesn't matter much at this point; 2) In arch/mips/au1000/common/sleeper.S, when the CPU regs are being restored on wakeup; Au1x00 PM code in 2.6 seem to have fallen out of maintenance, and the stack frame set up there seemed just erratic (2.4 situation in this module is much better). I didn't touch both those places. And of course, this CONFIG.OD bug is present in 2.4 kernels as well... WBR, Sergei From jcrouse@cosmic.amd.com Tue Nov 22 22:07:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 22:08:09 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:48875 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8134456AbVKVWHv (ORCPT ); Tue, 22 Nov 2005 22:07:51 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAMM8WtS015680; Tue, 22 Nov 2005 14:10:28 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 14:10:14 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAMMADZi025176; Tue, 22 Nov 2005 14:10:14 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 1E761201E; Tue, 22 Nov 2005 15:10:13 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAMMFQnv005453; Tue, 22 Nov 2005 15:15:26 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAMMFQIH005452; Tue, 22 Nov 2005 15:15:26 -0700 Date: Tue, 22 Nov 2005 15:15:26 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Subject: [PATCH] Fix board type in db1x00 Message-ID: <20051122221526.GZ18119@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D48CC2VS8368369-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 915 Lines: 33 Ok, one more one more from Sergei Shtylyov - add all the board types serviced by db1x00/init.c: ALCHEMY: Select correct machine type in db1x00 --- arch/mips/au1000/db1x00/init.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/arch/mips/au1000/db1x00/init.c b/arch/mips/au1000/db1x00/init.c index 4b9d5e4..41e0522 100644 --- a/arch/mips/au1000/db1x00/init.c +++ b/arch/mips/au1000/db1x00/init.c @@ -61,7 +61,17 @@ void __init prom_init(void) prom_envp = (char **) fw_arg2; mips_machgroup = MACH_GROUP_ALCHEMY; - mips_machtype = MACH_DB1000; /* set the platform # */ + + /* Set the platform # */ +#if defined (CONFIG_MIPS_DB1550) + mips_machtype = MACH_DB1550; +#elif defined (CONFIG_MIPS_DB1500) + mips_machtype = MACH_DB1500; +#elif defined (CONFIG_MIPS_DB1100) + mips_machtype = MACH_DB1100; +#else + mips_machtype = MACH_DB1000; +#endif prom_init_cmdline(); From dan@embeddedalley.com Tue Nov 22 22:28:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Nov 2005 22:28:57 +0000 (GMT) Received: from smtp103.biz.mail.re2.yahoo.com ([68.142.229.217]:33957 "HELO smtp103.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8134167AbVKVW2j (ORCPT ); Tue, 22 Nov 2005 22:28:39 +0000 Received: (qmail 40186 invoked from network); 22 Nov 2005 22:31:14 -0000 Received: from unknown (HELO ?10.1.7.13?) (dan@embeddedalley.com@12.6.244.2 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 22 Nov 2005 22:31:14 -0000 In-Reply-To: <20051122221526.GZ18119@cosmic.amd.com> References: <20051122221526.GZ18119@cosmic.amd.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> Content-Transfer-Encoding: 7bit Cc: linux-mips@linux-mips.org, ralf@linux-mips.org From: Dan Malek Subject: Re: [PATCH] Fix board type in db1x00 Date: Tue, 22 Nov 2005 17:31:20 -0500 To: "Jordan Crouse" X-Mailer: Apple Mail (2.623) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9542 X-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: 567 Lines: 27 On Nov 22, 2005, at 5:15 PM, Jordan Crouse wrote: > + /* Set the platform # */ > +#if defined (CONFIG_MIPS_DB1550) > + mips_machtype = MACH_DB1550; > +#elif defined (CONFIG_MIPS_DB1500) > + mips_machtype = MACH_DB1500; > +#elif defined (CONFIG_MIPS_DB1100) > + mips_machtype = MACH_DB1100; > +#else > + mips_machtype = MACH_DB1000; > +#endif Can't we just do something like #define MACH_ALCHEMY_TYPE xxxxx in the include files and not have this mess in the actual code? Then, all we have to do here is: mips_machtype = MACH_ALCHEMY_TYPE; Thanks. -- Dan From jcrouse@cosmic.amd.com Wed Nov 23 00:07:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 00:08:15 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:12758 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8134456AbVKWAHy (ORCPT ); Wed, 23 Nov 2005 00:07:54 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAN0AUno025543; Tue, 22 Nov 2005 18:10:30 -0600 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 18:10:21 -0600 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAN0ALeP026648; Tue, 22 Nov 2005 18:10:21 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 61F771FF4; Tue, 22 Nov 2005 17:10:20 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAN0FY5e006378; Tue, 22 Nov 2005 17:15:34 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAN0FYUc006377; Tue, 22 Nov 2005 17:15:34 -0700 Date: Tue, 22 Nov 2005 17:15:34 -0700 From: "Jordan Crouse" To: "Dan Malek" cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: Fix board type in db1x00 Message-ID: <20051123001534.GA18119@cosmic.amd.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> MIME-Version: 1.0 In-Reply-To: <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D6CE72EC608102-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1167 Lines: 39 On 22/11/05 17:31 -0500, Dan Malek wrote: > > On Nov 22, 2005, at 5:15 PM, Jordan Crouse wrote: > > >+ /* Set the platform # */ > >+#if defined (CONFIG_MIPS_DB1550) > >+ mips_machtype = MACH_DB1550; > >+#elif defined (CONFIG_MIPS_DB1500) > >+ mips_machtype = MACH_DB1500; > >+#elif defined (CONFIG_MIPS_DB1100) > >+ mips_machtype = MACH_DB1100; > >+#else > >+ mips_machtype = MACH_DB1000; > >+#endif > > Can't we just do something like > #define MACH_ALCHEMY_TYPE xxxxx > > in the include files and not have this mess in the > actual code? Then, all we have to do here is: > > mips_machtype = MACH_ALCHEMY_TYPE; The problem with db1x00 in particular is that its sort of a catch all for all the Alchemy boards that don't have a proper home of their own, so there really isn't a DB1000/DB1100/DB1500/DB1550 header file. That means either the mess goes in here or it goes in asm-mips/mach-db1x00/db1x00.h, and I think I rather prefer it to be in the .c file, just so one doesn't have to chase down the MACH_ALCHEMY_TYPE define. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From dan@embeddedalley.com Wed Nov 23 00:22:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 00:22:30 +0000 (GMT) Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]:52835 "HELO smtp102.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8134463AbVKWAWM (ORCPT ); Wed, 23 Nov 2005 00:22:12 +0000 Received: (qmail 75346 invoked from network); 23 Nov 2005 00:24:48 -0000 Received: from unknown (HELO ?192.168.253.28?) (dan@embeddedalley.com@209.113.146.155 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 23 Nov 2005 00:24:48 -0000 In-Reply-To: <20051123001534.GA18119@cosmic.amd.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <20051123001534.GA18119@cosmic.amd.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <968d9f47767cad14f9924abc1d07972b@embeddedalley.com> Content-Transfer-Encoding: 7bit Cc: linux-mips@linux-mips.org, ralf@linux-mips.org From: Dan Malek Subject: Re: Fix board type in db1x00 Date: Tue, 22 Nov 2005 19:24:51 -0500 To: "Jordan Crouse" X-Mailer: Apple Mail (2.623) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9544 X-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: 703 Lines: 20 On Nov 22, 2005, at 7:15 PM, Jordan Crouse wrote: > .... That means either the mess goes in here or it goes > in asm-mips/mach-db1x00/db1x00.h, You are already doing this for other things, like the BCSR differences with the db1550. Why not put it all on one place? You could even generate out of the Kconfig process and not need it in any file. :-) The problem is if you propagate stuff like this "... because there isn't an include file ..." others will also take that attitude. Someone has to start the process. For something as generic as these boards, the next one should simply be an include file update, not the need to edit various source files as is necessary today. Thanks. -- Dan From jcrouse@cosmic.amd.com Wed Nov 23 01:11:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 01:11:24 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:740 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8134465AbVKWBLC (ORCPT ); Wed, 23 Nov 2005 01:11:02 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAN1DeTs012025; Tue, 22 Nov 2005 19:13:40 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Nov 2005 19:13:31 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAN1DUeP004994; Tue, 22 Nov 2005 19:13:30 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 631041FF4; Tue, 22 Nov 2005 18:13:30 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAN1IjOF007058; Tue, 22 Nov 2005 18:18:45 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAN1Ij9r007057; Tue, 22 Nov 2005 18:18:45 -0700 Date: Tue, 22 Nov 2005 18:18:45 -0700 From: "Jordan Crouse" To: "Dan Malek" cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: Fix board type in db1x00 Message-ID: <20051123011845.GA6502@cosmic.amd.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <20051123001534.GA18119@cosmic.amd.com> <968d9f47767cad14f9924abc1d07972b@embeddedalley.com> MIME-Version: 1.0 In-Reply-To: <968d9f47767cad14f9924abc1d07972b@embeddedalley.com> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F9D1DB11M8617281-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1246 Lines: 33 On 22/11/05 19:24 -0500, Dan Malek wrote: > > On Nov 22, 2005, at 7:15 PM, Jordan Crouse wrote: > > >.... That means either the mess goes in here or it goes > >in asm-mips/mach-db1x00/db1x00.h, > > You are already doing this for other things, like the BCSR > differences with the db1550. Why not put it all on one place? > You could even generate out of the Kconfig process and > not need it in any file. :-) The problem is if you propagate > stuff like this "... because there isn't an include file ..." others > will also take that attitude. Someone has to start the > process. For something as generic as these boards, the > next one should simply be an include file update, not the > need to edit various source files as is necessary today. I'll buy into the general idea, but I'll defer to Ralf to see if he wants us to start inflicting this on the tree, or if he would just prefer to let sleeping dogs lay. One one hand, its nice to clean things up, but on the other hand, we're not making any more DB boards :( so its doubtful the ugliness will grow much further then this. Thanks for your comments, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From fung@cohut.net Wed Nov 23 03:24:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 03:25:09 +0000 (GMT) Received: from wmail06.netvigator.com ([218.102.48.220]:5927 "EHLO wmail05dat.netvigator.com") by ftp.linux-mips.org with ESMTP id S8134462AbVKWDYv (ORCPT ); Wed, 23 Nov 2005 03:24:51 +0000 Received: from cohut.net ([203.218.199.245]) by wmail05dat.netvigator.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051123032723.LTVY722.wmail05dat.netvigator.com@cohut.net> for ; Wed, 23 Nov 2005 11:27:23 +0800 Received: from cohut.net (localhost.localdomain [127.0.0.1]) by cohut.net (8.13.4/8.13.4) with ESMTP id jAN3RI3G031734 for ; Wed, 23 Nov 2005 11:27:18 +0800 Received: (from fung@localhost) by cohut.net (8.13.4/8.13.1/Submit) id jAN3RIIO031731 for linux-mips@linux-mips.org; Wed, 23 Nov 2005 11:27:18 +0800 Date: Wed, 23 Nov 2005 11:27:13 +0800 From: Co Ngai Fung To: linux-mips@linux-mips.org Subject: Timer interrupt handler problem Message-ID: <20051123032713.GA31683@pig.cohut.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fung@cohut.net Precedence: bulk X-list: linux-mips Content-Length: 761 Lines: 25 Hi, I want to use the timer16, I can control the timer with the timer16_ctl(), but the prolem is that when the timer countdown to zero, I can't use the interrupt handler to get this event, i have the following code for setup the interrupt handler. request_irq(SYS_TIMER_0_IRQ, timer_timeout_intr, SA_INTERRUPT, "AC49X timer", NULL); where the AC49X_SYS_TIMER_0_IRQ is 5, and timer_timeout_intr() is just a function to printk a line out. I want to know is just that simple to call request_irq() to have the interrupt handler be called when the interrupt is issued? Thanks! Co Ngai Fung -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ living is easy with eyes closed, misunderstanding all you see. - strawberry fields forever ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From matej.kupljen@ultra.si Wed Nov 23 06:29:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 06:29:33 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:50571 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133476AbVKWG3G (ORCPT ); Wed, 23 Nov 2005 06:29:06 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 4405BC058; Wed, 23 Nov 2005 07:31:44 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id AB6091BC08D; Wed, 23 Nov 2005 07:31:45 +0100 (CET) Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52]) by smtp.triera.net (Postfix) with ESMTP id 101B51A18AB; Wed, 23 Nov 2005 07:31:41 +0100 (CET) Subject: Re: [PATCH] Fix board type in db1x00 From: Matej Kupljen To: Dan Malek Cc: Jordan Crouse , linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> Content-Type: text/plain Organization: Ultra d.o.o. Date: Wed, 23 Nov 2005 07:31:37 +0100 Message-Id: <1132727497.10318.8.camel@orionlinux.starfleet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9547 X-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: 701 Lines: 30 Hi > > + /* Set the platform # */ > > +#if defined (CONFIG_MIPS_DB1550) > > + mips_machtype = MACH_DB1550; > > +#elif defined (CONFIG_MIPS_DB1500) > > + mips_machtype = MACH_DB1500; > > +#elif defined (CONFIG_MIPS_DB1100) > > + mips_machtype = MACH_DB1100; > > +#else > > + mips_machtype = MACH_DB1000; > > +#endif > > Can't we just do something like > #define MACH_ALCHEMY_TYPE xxxxx > > in the include files and not have this mess in the > actual code? Then, all we have to do here is: > > mips_machtype = MACH_ALCHEMY_TYPE; I prefer Dan's suggestion, if it counts. And please, don't forget about DB1200 board also. I already sent some minor patches, but they didn't get in :( BR, Matej From ralf@linux-mips.org Wed Nov 23 09:51:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 09:52:14 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:48666 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133577AbVKWJv4 (ORCPT ); Wed, 23 Nov 2005 09:51:56 +0000 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 jAN9saDn004806; Wed, 23 Nov 2005 09:54:36 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAN9sZN6004805; Wed, 23 Nov 2005 09:54:35 GMT Date: Wed, 23 Nov 2005 09:54:35 +0000 From: Ralf Baechle To: "Knittel, Brian" Cc: linux-mips@linux-mips.org, Dominic Sweetman Subject: Re: Saving arguments on the stack Message-ID: <20051123095435.GB2699@linux-mips.org> References: <762C0A863A7674478671627FEAF5848105AF92D5@hqmail01.powertv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <762C0A863A7674478671627FEAF5848105AF92D5@hqmail01.powertv.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9548 X-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: 885 Lines: 17 On Tue, Nov 22, 2005 at 10:24:09AM -0800, Knittel, Brian wrote: > We'd like to add arguments to the backtrace in Oops messages to make > debugging from these reports more efficient. It is particularly useful > for determining where the problem was generated, particularly when bad > pointers are passed in. This is for production embedded devices with > optimized code and which reboot immediately after storing or sending the > Oops message. Performance is an issue, but the overhead of storing the > arguments on the stack is likely worth the added debug info. In this case you would probably have to modify the compiler to save all arguments. Another issue is actually finding the stackframe. For a debugger using debug information this is possible but short of that it's hard on MIPS to produce a meaningful backtrace. Or having something as complicate as on ia64 ... Ralf From dan@embeddedalley.com Wed Nov 23 14:39:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 14:39:34 +0000 (GMT) Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]:50261 "HELO smtp102.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8133593AbVKWOjP (ORCPT ); Wed, 23 Nov 2005 14:39:15 +0000 Received: (qmail 14724 invoked from network); 23 Nov 2005 14:39:07 -0000 Received: from unknown (HELO ?192.168.2.27?) (dan@embeddedalley.com@69.21.252.132 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 23 Nov 2005 14:39:07 -0000 In-Reply-To: <1132727497.10318.8.camel@orionlinux.starfleet.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <1132727497.10318.8.camel@orionlinux.starfleet.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Jordan Crouse , linux-mips@linux-mips.org, ralf@linux-mips.org From: Dan Malek Subject: Re: [PATCH] Fix board type in db1x00 Date: Wed, 23 Nov 2005 09:39:15 -0500 To: Matej Kupljen X-Mailer: Apple Mail (2.623) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9549 X-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: 362 Lines: 16 On Nov 23, 2005, at 1:31 AM, Matej Kupljen wrote: > And please, don't forget about DB1200 board also. > I already sent some minor patches, but they didn't > get in :( They didn't get lost. Pete and I knew there would be things coming from AMD, there are several other patches that have been posted. We just need to merge it all together. Thanks. -- Dan From Brian.Knittel@powertv.com Wed Nov 23 18:33:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Nov 2005 18:34:08 +0000 (GMT) Received: from mask.powertv.com ([12.146.136.163]:15997 "EHLO hqmail01.powertv.com") by ftp.linux-mips.org with ESMTP id S3466586AbVKWSdv (ORCPT ); Wed, 23 Nov 2005 18:33:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: Saving arguments on the stack Date: Wed, 23 Nov 2005 10:36:31 -0800 Message-ID: <762C0A863A7674478671627FEAF5848105AF92D7@hqmail01.powertv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Saving arguments on the stack Thread-Index: AcXwE/B0diNaHx97QjigLmJi1z4CvAAR57vG From: "Knittel, Brian" To: "Ralf Baechle" Cc: , "Dominic Sweetman" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Brian.Knittel@powertv.com Precedence: bulk X-list: linux-mips Content-Length: 2112 Lines: 28 SGkgUmFsZiwNCiANCkkndmUgd29ya2VkIG91dCB0aGUgYmFja3RyYWNlLiBDaGFuZ2luZyB0aGUg Y29tcGlsZXIgaXMgcHJvYmFibHkgbm90IGFuIG9wdGlvbi4gT25lIGNvbGxlYWd1ZSBoYXMgc3Vn Z2VzdGVkIHRoYXQgd2l0aCBzeXN0ZW1zIHdpdGggcmVhc29uYWJsZSBzaXplIGNhY2hlcywgbm90 IHNhdmluZyB0aGUgYXJndW1lbnRzIG9uIHRoZSBzdGFjayBkb2VzIG5vdCBwcm92aWRlIHNpZ25p ZmljYW50IHBlcmZvcm1hbmNlIGltcHJvdmVtZW50LiBJJ20gc3VyZSB0aGF0IGRlcGVuZHMgdXBv biB3aGF0IHlvdSBhcmUgZG9pbmcsIGJ1dCBJIHN1c3BlY3QgaGUgaXMgcmlnaHQgZm9yIHRoZSBt b3N0IHBhcnQuIA0KIA0KQ29tbWVudHMsIGFueW9uZT8NCiANClRoYW5rcywNCi0tQnJpYW4NCg0K CS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IFJhbGYgQmFlY2hsZSBbbWFpbHRv OnJhbGZAbGludXgtbWlwcy5vcmddIA0KCVNlbnQ6IFdlZCAxMS8yMy8yMDA1IDE6NTQgQU0gDQoJ VG86IEtuaXR0ZWwsIEJyaWFuIA0KCUNjOiBsaW51eC1taXBzQGxpbnV4LW1pcHMub3JnOyBEb21p bmljIFN3ZWV0bWFuIA0KCVN1YmplY3Q6IFJlOiBTYXZpbmcgYXJndW1lbnRzIG9uIHRoZSBzdGFj aw0KCQ0KCQ0KDQoJT24gVHVlLCBOb3YgMjIsIDIwMDUgYXQgMTA6MjQ6MDlBTSAtMDgwMCwgS25p dHRlbCwgQnJpYW4gd3JvdGU6DQoJDQoJPiBXZSdkIGxpa2UgdG8gYWRkIGFyZ3VtZW50cyB0byB0 aGUgYmFja3RyYWNlIGluIE9vcHMgbWVzc2FnZXMgdG8gbWFrZQ0KCT4gZGVidWdnaW5nIGZyb20g dGhlc2UgcmVwb3J0cyBtb3JlIGVmZmljaWVudC4gSXQgaXMgcGFydGljdWxhcmx5IHVzZWZ1bA0K CT4gZm9yIGRldGVybWluaW5nIHdoZXJlIHRoZSBwcm9ibGVtIHdhcyBnZW5lcmF0ZWQsIHBhcnRp Y3VsYXJseSB3aGVuIGJhZA0KCT4gcG9pbnRlcnMgYXJlIHBhc3NlZCBpbi4gVGhpcyBpcyBmb3Ig cHJvZHVjdGlvbiBlbWJlZGRlZCBkZXZpY2VzIHdpdGgNCgk+IG9wdGltaXplZCBjb2RlIGFuZCB3 aGljaCByZWJvb3QgaW1tZWRpYXRlbHkgYWZ0ZXIgc3RvcmluZyBvciBzZW5kaW5nIHRoZQ0KCT4g T29wcyBtZXNzYWdlLiBQZXJmb3JtYW5jZSBpcyBhbiBpc3N1ZSwgYnV0IHRoZSBvdmVyaGVhZCBv ZiBzdG9yaW5nIHRoZQ0KCT4gYXJndW1lbnRzIG9uIHRoZSBzdGFjayBpcyBsaWtlbHkgd29ydGgg dGhlIGFkZGVkIGRlYnVnIGluZm8uDQoJDQoJSW4gdGhpcyBjYXNlIHlvdSB3b3VsZCBwcm9iYWJs eSBoYXZlIHRvIG1vZGlmeSB0aGUgY29tcGlsZXIgdG8gc2F2ZSBhbGwNCglhcmd1bWVudHMuICBB bm90aGVyIGlzc3VlIGlzIGFjdHVhbGx5IGZpbmRpbmcgdGhlIHN0YWNrZnJhbWUuICBGb3IgYQ0K CWRlYnVnZ2VyIHVzaW5nIGRlYnVnIGluZm9ybWF0aW9uIHRoaXMgaXMgcG9zc2libGUgYnV0IHNo b3J0IG9mIHRoYXQgaXQncw0KCWhhcmQgb24gTUlQUyB0byBwcm9kdWNlIGEgbWVhbmluZ2Z1bCBi YWNrdHJhY2UuICBPciBoYXZpbmcgc29tZXRoaW5nDQoJYXMgY29tcGxpY2F0ZSBhcyBvbiBpYTY0 IC4uLg0KCQ0KCSAgUmFsZg0KCQ0KDQo= From anemo@mba.ocn.ne.jp Thu Nov 24 07:31:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Nov 2005 07:32:09 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:27934 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133452AbVKXHbu (ORCPT ); Thu, 24 Nov 2005 07:31:50 +0000 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; 24 Nov 2005 07:35:48 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 35FC4200B0; Thu, 24 Nov 2005 16:35:44 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 215F41FFB9; Thu, 24 Nov 2005 16:35:44 +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 jAO7Zh4D081281; Thu, 24 Nov 2005 16:35:44 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 24 Nov 2005 16:35:42 +0900 (JST) Message-Id: <20051124.163542.66180964.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] gdb-stub.c build fix From: Atsushi Nemoto 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9551 X-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: 495 Lines: 17 Remove a semicolon to fix build error. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/gdb-stub.c b/arch/mips/kernel/gdb-stub.c index 96d18c4..9fedfa4 100644 --- a/arch/mips/kernel/gdb-stub.c +++ b/arch/mips/kernel/gdb-stub.c @@ -178,7 +178,7 @@ int kgdb_enabled; */ static DEFINE_SPINLOCK(kgdb_lock); static raw_spinlock_t kgdb_cpulock[NR_CPUS] = { - [0 ... NR_CPUS-1] = __RAW_SPIN_LOCK_UNLOCKED; + [0 ... NR_CPUS-1] = __RAW_SPIN_LOCK_UNLOCKED }; /* From anemo@mba.ocn.ne.jp Thu Nov 24 07:46:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Nov 2005 07:47:06 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:45828 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133452AbVKXHqr (ORCPT ); Thu, 24 Nov 2005 07:46:47 +0000 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; 24 Nov 2005 07:50:46 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 4A36020088; Thu, 24 Nov 2005 16:50:44 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 37D272007A; Thu, 24 Nov 2005 16:50:44 +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 jAO7oh4D081338; Thu, 24 Nov 2005 16:50:44 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 24 Nov 2005 16:50:43 +0900 (JST) Message-Id: <20051124.165043.112050815.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix gdb-stub for kernel compiled with higher ISA level From: Atsushi Nemoto 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9552 X-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: 3586 Lines: 114 The modern gdb seems to require 64bit values in remote packet for 32bit kernel which is compiled with -march=mips3, etc. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/gdb-stub.c b/arch/mips/kernel/gdb-stub.c index 96d18c4..9fedfa4 100644 --- a/arch/mips/kernel/gdb-stub.c +++ b/arch/mips/kernel/gdb-stub.c @@ -670,6 +670,13 @@ static void kgdb_wait(void *arg) } +#if defined(CONFIG_32BIT) && \ + (_MIPS_ISA == _MIPS_ISA_MIPS3 || \ + _MIPS_ISA == _MIPS_ISA_MIPS4 || \ + _MIPS_ISA == _MIPS_ISA_MIPS5 || \ + _MIPS_ISA == _MIPS_ISA_MIPS64) +#define GDB_EXPECT_64BIT_REG +#endif /* * This function does all command processing for interfacing to gdb. It * returns 1 if you should skip the instruction at the trap address, 0 @@ -685,6 +692,9 @@ void handle_exception (struct gdb_regs * unsigned long *stack; int i; int bflag = 0; +#ifdef GDB_EXPECT_64BIT_REG + u64 tmp64; +#endif kgdb_started = 1; @@ -762,7 +772,12 @@ void handle_exception (struct gdb_regs * *ptr++ = hexchars[REG_EPC >> 4]; *ptr++ = hexchars[REG_EPC & 0xf]; *ptr++ = ':'; +#ifdef GDB_EXPECT_64BIT_REG + tmp64 = regs->cp0_epc; + ptr = mem2hex((char *)&tmp64, ptr, sizeof(u64), 0); +#else ptr = mem2hex((char *)®s->cp0_epc, ptr, sizeof(long), 0); +#endif *ptr++ = ';'; /* @@ -771,7 +786,12 @@ void handle_exception (struct gdb_regs * *ptr++ = hexchars[REG_FP >> 4]; *ptr++ = hexchars[REG_FP & 0xf]; *ptr++ = ':'; +#ifdef GDB_EXPECT_64BIT_REG + tmp64 = regs->reg30; + ptr = mem2hex((char *)&tmp64, ptr, sizeof(u64), 0); +#else ptr = mem2hex((char *)®s->reg30, ptr, sizeof(long), 0); +#endif *ptr++ = ';'; /* @@ -780,7 +800,12 @@ void handle_exception (struct gdb_regs * *ptr++ = hexchars[REG_SP >> 4]; *ptr++ = hexchars[REG_SP & 0xf]; *ptr++ = ':'; +#ifdef GDB_EXPECT_64BIT_REG + tmp64 = regs->reg29; + ptr = mem2hex((char *)&tmp64, ptr, sizeof(u64), 0); +#else ptr = mem2hex((char *)®s->reg29, ptr, sizeof(long), 0); +#endif *ptr++ = ';'; *ptr++ = 0; @@ -819,12 +844,19 @@ void handle_exception (struct gdb_regs * */ case 'g': ptr = output_buffer; +#ifdef GDB_EXPECT_64BIT_REG + for (i = 0; i < 32 + 6 + 32 + 2 + 2 + 16; i++) { + tmp64 = *(®s->reg0 + i); + ptr = mem2hex((char *)&tmp64, ptr, sizeof(u64), 0); + } +#else ptr = mem2hex((char *)®s->reg0, ptr, 32*sizeof(long), 0); /* r0...r31 */ ptr = mem2hex((char *)®s->cp0_status, ptr, 6*sizeof(long), 0); /* cp0 */ ptr = mem2hex((char *)®s->fpr0, ptr, 32*sizeof(long), 0); /* f0...31 */ ptr = mem2hex((char *)®s->cp1_fsr, ptr, 2*sizeof(long), 0); /* cp1 */ ptr = mem2hex((char *)®s->frame_ptr, ptr, 2*sizeof(long), 0); /* frp */ ptr = mem2hex((char *)®s->cp0_index, ptr, 16*sizeof(long), 0); /* cp0 */ +#endif break; /* @@ -833,6 +865,13 @@ void handle_exception (struct gdb_regs * case 'G': { ptr = &input_buffer[1]; +#ifdef GDB_EXPECT_64BIT_REG + for (i = 0; i < 32 + 6 + 32 + 2 + 2 + 16; i++) { + hex2mem(ptr, (char *)&tmp64, sizeof(u64), 0, 0); + *(®s->reg0 + i) = (long)tmp64; + ptr += 2*sizeof(u64); + } +#else hex2mem(ptr, (char *)®s->reg0, 32*sizeof(long), 0, 0); ptr += 32*(2*sizeof(long)); hex2mem(ptr, (char *)®s->cp0_status, 6*sizeof(long), 0, 0); @@ -844,6 +883,7 @@ void handle_exception (struct gdb_regs * hex2mem(ptr, (char *)®s->frame_ptr, 2*sizeof(long), 0, 0); ptr += 2*(2*sizeof(long)); hex2mem(ptr, (char *)®s->cp0_index, 16*sizeof(long), 0, 0); +#endif strcpy(output_buffer,"OK"); } break; From sshtylyov@dev.rtsoft.ru Fri Nov 25 19:03:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Nov 2005 19:03:23 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:41167 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S3466664AbVKYTDF (ORCPT ); Fri, 25 Nov 2005 19:03:05 +0000 Received: (qmail 1245 invoked from network); 25 Nov 2005 19:05:59 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 25 Nov 2005 19:05:59 -0000 Message-ID: <43876118.3060503@dev.rtsoft.ru> Date: Fri, 25 Nov 2005 22:08:08 +0300 From: Sergei Shtylyov Organization: RTSoft, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Jordan Crusoe , Manish Lachwani Subject: [PATCH] Fix Au1550 OHCI memory map size Content-Type: multipart/mixed; boundary="------------060800070208090600080108" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@dev.rtsoft.ru Precedence: bulk X-list: linux-mips Content-Length: 1616 Lines: 59 This is a multi-part message in MIME format. --------------060800070208090600080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. USB OpenHCI host controller on Au1550 only decodes memory addresses from 0x14020000 to 0x1407FFFF according to the databook, which gives 0x60000 (on the prior Au1x00 chips the map size was 1MB). WBR, Sergei Signed-off-by: Sergei Shtylyov --------------060800070208090600080108 Content-Type: text/plain; name="Au1550-OHCI-mem-size.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Au1550-OHCI-mem-size.patch" diff --git a/include/asm-mips/mach-au1x00/au1000.h b/include/asm-mips/mach-au1x00/au1000.h index 8327ec3..8e1d7ed 100644 --- a/include/asm-mips/mach-au1x00/au1000.h +++ b/include/asm-mips/mach-au1x00/au1000.h @@ -838,6 +838,7 @@ extern au1xxx_irq_map_t au1xxx_irq_map[] #define UART3_ADDR 0xB1400000 #define USB_OHCI_BASE 0x14020000 // phys addr for ioremap +#define USB_OHCI_LEN 0x00060000 #define USB_HOST_CONFIG 0xB4027ffc #define AU1550_ETH0_BASE 0xB0500000 @@ -1017,10 +1018,12 @@ extern au1xxx_irq_map_t au1xxx_irq_map[] #define I2S_CONTROL_D (1<<1) #define I2S_CONTROL_CE (1<<0) -#ifndef CONFIG_SOC_AU1200 - /* USB Host Controller */ +#ifndef USB_OHCI_LEN #define USB_OHCI_LEN 0x00100000 +#endif + +#ifndef CONFIG_SOC_AU1200 /* USB Device Controller */ #define USBD_EP0RD 0xB0200000 --------------060800070208090600080108-- From drow@nevyn.them.org Fri Nov 25 19:24:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Nov 2005 19:25:03 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:13269 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S3466664AbVKYTYp (ORCPT ); Fri, 25 Nov 2005 19:24:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EfjEU-0001am-Os; Fri, 25 Nov 2005 14:27:42 -0500 Date: Fri, 25 Nov 2005 14:27:42 -0500 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] fix gdb-stub for kernel compiled with higher ISA level Message-ID: <20051125192742.GA6013@nevyn.them.org> References: <20051124.165043.112050815.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051124.165043.112050815.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9554 X-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: 547 Lines: 15 On Thu, Nov 24, 2005 at 04:50:43PM +0900, Atsushi Nemoto wrote: > The modern gdb seems to require 64bit values in remote packet for > 32bit kernel which is compiled with -march=mips3, etc. FYI, it is a known limitation in GDB that it can't cope with either format, and I hope to fix it sometime soon. It's definitely a bug that it expects 64-bit registers for mips3 32-bit binaries; I think the change in question was crazy... You can "set architecture mips:isa32" before connecting to get around this. -- Daniel Jacobowitz CodeSourcery, LLC From anemo@mba.ocn.ne.jp Sat Nov 26 16:13:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Nov 2005 16:14:08 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:22010 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133637AbVKZQNu (ORCPT ); Sat, 26 Nov 2005 16:13:50 +0000 Received: from localhost (p1238-ipad202funabasi.chiba.ocn.ne.jp [222.146.72.238]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 1393AA217; Sun, 27 Nov 2005 01:16:51 +0900 (JST) Date: Sun, 27 Nov 2005 01:16:04 +0900 (JST) Message-Id: <20051127.011604.41198575.anemo@mba.ocn.ne.jp> To: dan@debian.org Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] fix gdb-stub for kernel compiled with higher ISA level From: Atsushi Nemoto In-Reply-To: <20051125192742.GA6013@nevyn.them.org> References: <20051124.165043.112050815.nemoto@toshiba-tops.co.jp> <20051125192742.GA6013@nevyn.them.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.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9555 X-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: 624 Lines: 17 >>>>> On Fri, 25 Nov 2005 14:27:42 -0500, Daniel Jacobowitz said: dan> FYI, it is a known limitation in GDB that it can't cope with dan> either format, and I hope to fix it sometime soon. It's dan> definitely a bug that it expects 64-bit registers for mips3 dan> 32-bit binaries; I think the change in question was crazy... dan> You can "set architecture mips:isa32" before connecting to get dan> around this. Thank you for the information. Then I revoke this patch. Ralf, please ignore this patch. (And please apply my another gdb-stub patch which is just fix a build error ...) --- Atsushi Nemoto From drow@nevyn.them.org Sun Nov 27 03:31:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 27 Nov 2005 03:31:53 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:11168 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133767AbVK0Dbf (ORCPT ); Sun, 27 Nov 2005 03:31:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EgDJJ-0008Pd-G0; Sat, 26 Nov 2005 22:34:41 -0500 Date: Sat, 26 Nov 2005 22:34:41 -0500 From: Daniel Jacobowitz To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Generate SIGILL again Message-ID: <20051127033441.GA32180@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9556 X-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: 689 Lines: 30 The rdhwr emulation accidentally swallowed the SIGILL from most other illegal instructions. Make sure to return -EFAULT by default. Signed-off-by: Daniel Jacobowitz diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 7f60f61..63db2fa 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -534,13 +534,14 @@ static inline int simulate_rdhwr(struct switch (rd) { case 29: regs->regs[rt] = ti->tp_value; - break; + return 0; default: return -EFAULT; } } - return 0; + /* Not ours. */ + return -EFAULT; } asmlinkage void do_ov(struct pt_regs *regs) -- Daniel Jacobowitz CodeSourcery, LLC From matej.kupljen@ultra.si Mon Nov 28 10:34:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Nov 2005 10:34:46 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:39613 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133396AbVK1Ke2 (ORCPT ); Mon, 28 Nov 2005 10:34:28 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 013F1C00C for ; Mon, 28 Nov 2005 11:37:34 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id C14C81BC08C for ; Mon, 28 Nov 2005 11:37:36 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 695961A18AE for ; Mon, 28 Nov 2005 11:37:36 +0100 (CET) Subject: PIC/Cardbus on AU1200 From: Matej Kupljen To: linux-mips@linux-mips.org Content-Type: text/plain Date: Mon, 28 Nov 2005 11:37:19 +0100 Message-Id: <1133174239.11413.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9557 X-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: 311 Lines: 14 Hi We'd like to add a Cardbus to the AMD AU1200 CPU. Does anybody has any experience in this? I've seen that many ARM boards uses IT8152 IC from ITE, however I cannot find any more information about it. Does any bod know for a PCI (or Cardbus) controller, that can connect easily to the AU1200? BR, Matej From ralf@linux-mips.org Tue Nov 29 16:51:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Nov 2005 16:52:10 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:22046 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133755AbVK2Qvx (ORCPT ); Tue, 29 Nov 2005 16:51:53 +0000 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 jATGpo95023037; Tue, 29 Nov 2005 16:51:50 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jATGpmV1023036; Tue, 29 Nov 2005 16:51:48 GMT Date: Tue, 29 Nov 2005 16:51:48 +0000 From: Ralf Baechle To: Dan Malek Cc: Jordan Crouse , linux-mips@linux-mips.org Subject: Re: [PATCH] Fix board type in db1x00 Message-ID: <20051129165148.GA20402@linux-mips.org> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9558 X-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: 813 Lines: 28 On Tue, Nov 22, 2005 at 05:31:20PM -0500, Dan Malek wrote: > On Nov 22, 2005, at 5:15 PM, Jordan Crouse wrote: > > >+ /* Set the platform # */ > >+#if defined (CONFIG_MIPS_DB1550) > >+ mips_machtype = MACH_DB1550; > >+#elif defined (CONFIG_MIPS_DB1500) > >+ mips_machtype = MACH_DB1500; > >+#elif defined (CONFIG_MIPS_DB1100) > >+ mips_machtype = MACH_DB1100; > >+#else > >+ mips_machtype = MACH_DB1000; > >+#endif > > Can't we just do something like > #define MACH_ALCHEMY_TYPE xxxxx > > in the include files and not have this mess in the > actual code? Then, all we have to do here is: > > mips_machtype = MACH_ALCHEMY_TYPE; But we don't have a nice space for this in header files either right now. So I'll apply this one but if you come up with something better I'll certainly appreciate it. Ralf From anemo@mba.ocn.ne.jp Wed Nov 30 04:28:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 04:29:16 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:6936 "HELO topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP id S8133362AbVK3E26 (ORCPT ); Wed, 30 Nov 2005 04:28:58 +0000 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; 30 Nov 2005 04:33:31 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 7148C2017A; Wed, 30 Nov 2005 13:33:27 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 65B1320034; Wed, 30 Nov 2005 13:33:27 +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 jAU4XQ4D010653; Wed, 30 Nov 2005 13:33:27 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 30 Nov 2005 13:33:26 +0900 (JST) Message-Id: <20051130.133326.126937941.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix mdelay(1) for 64bit kernel with HZ == 1000 From: Atsushi Nemoto 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: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9559 X-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: 1147 Lines: 29 mdelay(1) (i.e. udelay(1000)) does not work correctly due to overflow. 1000 * 0x004189374BC6A7f0 = 0x10000000000000180 (>= 2**64) 0x004189374BC6A7ef (0x004189374BC6A7f0 - 1) is OK and it is exactly same as catchall case (0x8000000000000000UL / (500000 / HZ)). Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/delay.h b/include/asm-mips/delay.h index 48d00cc..64dd451 100644 --- a/include/asm-mips/delay.h +++ b/include/asm-mips/delay.h @@ -52,13 +52,11 @@ static inline void __udelay(unsigned lon unsigned long lo; /* - * The common rates of 1000 and 128 are rounded wrongly by the - * catchall case for 64-bit. Excessive precission? Probably ... + * The rates of 128 is rounded wrongly by the catchall case + * for 64-bit. Excessive precission? Probably ... */ #if defined(CONFIG_64BIT) && (HZ == 128) usecs *= 0x0008637bd05af6c7UL; /* 2**64 / (1000000 / HZ) */ -#elif defined(CONFIG_64BIT) && (HZ == 1000) - usecs *= 0x004189374BC6A7f0UL; /* 2**64 / (1000000 / HZ) */ #elif defined(CONFIG_64BIT) usecs *= (0x8000000000000000UL / (500000 / HZ)); #else /* 32-bit junk follows here */ From matej.kupljen@ultra.si Wed Nov 30 08:32:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 08:32:53 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:28609 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133399AbVK3Icf (ORCPT ); Wed, 30 Nov 2005 08:32:35 +0000 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 11F43C02D; Wed, 30 Nov 2005 09:35:51 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 8D7381BC08F; Wed, 30 Nov 2005 09:35:52 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id CE5451A18CB; Wed, 30 Nov 2005 09:35:52 +0100 (CET) Subject: Re: [PATCH] Fix board type in db1x00 From: Matej Kupljen To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20051129165148.GA20402@linux-mips.org> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <20051129165148.GA20402@linux-mips.org> Content-Type: text/plain Date: Wed, 30 Nov 2005 09:35:27 +0100 Message-Id: <1133339727.24526.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9560 X-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: 212 Lines: 11 Hi > But we don't have a nice space for this in header files either right now. > So I'll apply this one but if you come up with something better I'll > certainly appreciate it. You forgot DBAU1200. BR, Matej From matej.kupljen@ultra.si Wed Nov 30 09:17:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 09:17:26 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:15052 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133533AbVK3JRI (ORCPT ); Wed, 30 Nov 2005 09:17:08 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id D6D5DC00F; Wed, 30 Nov 2005 10:20:26 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 2B6EB1BC08C; Wed, 30 Nov 2005 10:20:28 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 3D22B1A18B3; Wed, 30 Nov 2005 10:20:27 +0100 (CET) Subject: [PATCH] Simple patch to power off DBAU1200 From: Matej Kupljen To: linux-mips@linux-mips.org Cc: Jordan Crouse Content-Type: multipart/mixed; boundary="=-a7eAy1rQKAiMSuebxj5O" Date: Wed, 30 Nov 2005 10:20:01 +0100 Message-Id: <1133342401.24526.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9561 X-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: 906 Lines: 37 --=-a7eAy1rQKAiMSuebxj5O Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Please, find the attached patch which enables powering off the DBAU1200 board. BR, Matej --=-a7eAy1rQKAiMSuebxj5O Content-Disposition: attachment; filename=linux-2.6.14-dbau1200-poweroff.patch Content-Type: text/x-patch; name=linux-2.6.14-dbau1200-poweroff.patch; charset=us-ascii Content-Transfer-Encoding: 7bit Patch to enable powering off DBAU1200 Signed-off-by: Matej Kupljen --- a/arch/mips/au1000/common/reset.c 2005-10-24 13:36:24.000000000 +0200 +++ b/arch/mips/au1000/common/reset.c 2005-08-24 14:39:58.000000000 +0200 @@ -175,6 +175,9 @@ #ifdef CONFIG_MIPS_MIRAGE au_writel((1 << 26) | (1 << 10), GPIO2_OUTPUT); #endif +#ifdef CONFIG_MIPS_DB1200 + au_writew(au_readw(0xB980001C) | (1<<14), 0xB980001C); +#endif #ifdef CONFIG_PM au_sleep(); --=-a7eAy1rQKAiMSuebxj5O-- From david.sanchez@lexbox.fr Wed Nov 30 10:14:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 10:14:37 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:6636 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133460AbVK3KOR convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 10:14:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: DbAu1550 copy file corruption X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 30 Nov 2005 11:14:02 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E027190@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DbAu1550 copy file corruption thread-index: AcX1lsl8tmWJBo5gSmGMP3cNVuA5+w== From: "David Sanchez" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9562 X-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: 1986 Lines: 97 Hi, I still have a problem of file corruption after a big copy (around 300M) and no solution at this time... Who have a dbau1550 and who could try the following script to check copies on big files? #################################### #!/bin/sh path_file=$1 if test -z $path_file ; then path_file=`pwd` fi # You can modify the source and the destination filename, the source file # size and the number of iterations. # Source and destination filename src_file=${path_file}/src_test_file dst_file=${path_file}/dst_test_file # Source file size: 300M src_file_size=300000 # Number of iterations let max_it=50 # Create source file if test ! -f ${src_file} ; then echo "* Generating ${src_file}..." dd bs=1024 count=${src_file_size} if=/dev/urandom of=${src_file} echo "" fi # Check if source exists if test -f ${src_file} ; then echo "* Check copy from $src_file to $dst_file:" echo "" else echo "$src_file does NOT exist" ; exec false fi # Clear destination if test -f ${dst_file} ; then rm ${dst_file} fi # Go let i=0 let nb_err=0 while [ $i -lt $max_it ] do cp ${src_file} ${dst_file} cmp ${src_file} ${dst_file} if [ $? -eq 0 ] then echo ${src_file} ${dst_file} IDENTICAL else let nb_err=nb_err+1 fi rm ${dst_file} let i=i+1 done # Result echo "" echo "Done" echo -e "\t$nb_err error(s) over $max_it iteration(s)" echo "" #################################### On my DbAu155 + Sata HDD on PDC20579 + Linux Kernel 2.6.10 + busybox 1.0: Each destination differs from the source: #################################### * Generating ./src_test_file... 300000+0 records in 300000+0 records out * Check copy from ./src_test_file to ./dst_test_file: ./src_test_file ./dst_test_file differ: char 10388254, line 40877 ./src_test_file ./dst_test_file differ: char 69932960, line 274140 ./src_test_file ./dst_test_file differ: char 36867840, line 144723 ... Done 50 error(s) over 50 iteration(s) #################################### Thanks' David From matej.kupljen@ultra.si Wed Nov 30 11:04:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 11:04:58 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:35812 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133460AbVK3LEj (ORCPT ); Wed, 30 Nov 2005 11:04:39 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 5345FC021; Wed, 30 Nov 2005 12:07:57 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 9894E1BC096; Wed, 30 Nov 2005 12:07:59 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id B676F1A18C1; Wed, 30 Nov 2005 12:07:58 +0100 (CET) Subject: MIPS no FP patch From: Matej Kupljen To: linux-mips@linux-mips.org Cc: Jordan Crouse Content-Type: multipart/mixed; boundary="=-AZcuWd0hzG6Kj7KQhnEu" Date: Wed, 30 Nov 2005 12:07:32 +0100 Message-Id: <1133348852.24526.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9563 X-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: 5495 Lines: 183 --=-AZcuWd0hzG6Kj7KQhnEu Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi This is a patch that makes FP emulation in kernel an option. I used this when I was looking why there are still some FP instruction in glibc, even though it was configured with --withot-fp. This seemed the best way to ensure this. It is for the 2.6.14-rc2, but I think there is only a minimal work to use it on latest kernel. BR, Matej --=-AZcuWd0hzG6Kj7KQhnEu Content-Disposition: attachment; filename=linux-2.6.14-rc2-no-fp.patch Content-Type: text/x-patch; name=linux-2.6.14-rc2-no-fp.patch; charset=us-ascii Content-Transfer-Encoding: 7bit Patch introduces a option, with which you can enable or disable the FP emulator in the kernel. It was written to ensure that no user space binaries uses FP instruction. This was necessary because glibc still contained some FP instructions even though it was configured with --without-fp and gcc with --with-float=soft. See for details and for patch. Signed-off-by: Matej Kupljen diff -ruN linux-latest/arch/mips/Kconfig linux-20051025-dbau1200/arch/mips/Kconfig --- linux-latest/arch/mips/Kconfig 2005-10-24 13:36:24.000000000 +0200 +++ linux-20051025-dbau1200/arch/mips/Kconfig 2005-11-30 11:14:59.823169816 +0100 @@ -1623,6 +1623,13 @@ source "kernel/Kconfig.preempt" +config MIPS_FPU_EMULATOR + bool "Include FPU emulator in the kernel" + default y + help + Enables or disables FP emulation in kernel. + If unsure, say YES + config RTC_DS1742 bool "DS1742 BRAM/RTC support" depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927 diff -ruN linux-latest/arch/mips/Makefile linux-20051025-dbau1200/arch/mips/Makefile --- linux-latest/arch/mips/Makefile 2005-10-24 13:36:24.000000000 +0200 +++ linux-20051025-dbau1200/arch/mips/Makefile 2005-11-30 10:45:12.000000000 +0100 @@ -752,7 +752,13 @@ libs-$(CONFIG_32BIT) += arch/mips/lib-32/ libs-$(CONFIG_64BIT) += arch/mips/lib-64/ -core-y += arch/mips/kernel/ arch/mips/mm/ arch/mips/math-emu/ +core-y += arch/mips/kernel/ arch/mips/mm/ + +ifdef CONFIG_MIPS_FPU_EMULATOR +core-y += arch/mips/math-emu/ +else +core-y += arch/mips/no-math-emu/ +endif drivers-$(CONFIG_OPROFILE) += arch/mips/oprofile/ diff -ruN linux-latest/arch/mips/no-math-emu/cp1emu.c linux-20051025-dbau1200/arch/mips/no-math-emu/cp1emu.c --- linux-latest/arch/mips/no-math-emu/cp1emu.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-20051025-dbau1200/arch/mips/no-math-emu/cp1emu.c 2005-11-30 11:44:16.410128008 +0100 @@ -0,0 +1,21 @@ +/* + * cp1emu.c: a MIPS coprocessor 1 (fpu) instruction emulator + * + * Dummy file that just calls BUG() when a coprocessor 1 + * instruction is encountered. + * It was wrtitten to ensure that no FP instruction is + * present in userspace binaries. + * + * Written by Matej Kupljen , 2005 + */ + +#include +#include +#include + +int fpu_emulator_cop1Handler(int xcptno, struct pt_regs *xcp, + struct mips_fpu_soft_struct *ctx) +{ + BUG(); + return 0; +} diff -ruN linux-latest/arch/mips/no-math-emu/dsemul.c linux-20051025-dbau1200/arch/mips/no-math-emu/dsemul.c --- linux-latest/arch/mips/no-math-emu/dsemul.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-20051025-dbau1200/arch/mips/no-math-emu/dsemul.c 2005-11-30 11:44:11.307903664 +0100 @@ -0,0 +1,14 @@ +/* + * Dummy file to support kernel without FP emulator. + * Matej Kupljen , 2005 + */ + +#include +#include +#include + +int do_dsemulret(struct pt_regs *xcp) +{ + BUG(); + return 1; +} diff -ruN linux-latest/arch/mips/no-math-emu/kernel_linkage.c linux-20051025-dbau1200/arch/mips/no-math-emu/kernel_linkage.c --- linux-latest/arch/mips/no-math-emu/kernel_linkage.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-20051025-dbau1200/arch/mips/no-math-emu/kernel_linkage.c 2005-11-30 11:44:05.818738144 +0100 @@ -0,0 +1,53 @@ +/* + * Kevin D. Kissell, kevink@mips and Carsten Langgaard, carstenl@mips.com + * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + * + * Dummy file to support kernel without FP emulator. + * + * Modified by Matej Kupljen , 2005 + */ + +#include +#include +#include + +void fpu_emulator_init_fpu(void) +{ + static int first = 1; + + if (first) { + first = 0; + printk("Kernel without FPU emulator!\n"); + } +} + +int fpu_emulator_save_context(struct sigcontext *sc) +{ + BUG(); + return -1; +} + +int fpu_emulator_restore_context(struct sigcontext *sc) +{ + BUG(); + return -1; +} + +#ifdef CONFIG_MIPS64 +/* + * This is the o32 version + */ + +int fpu_emulator_save_context32(struct sigcontext32 *sc) +{ + BUG(); + return -1; +} + +int fpu_emulator_restore_context32(struct sigcontext32 *sc) +{ + BUG(); + + return err; +} +#endif diff -ruN linux-latest/arch/mips/no-math-emu/Makefile linux-20051025-dbau1200/arch/mips/no-math-emu/Makefile --- linux-latest/arch/mips/no-math-emu/Makefile 1970-01-01 01:00:00.000000000 +0100 +++ linux-20051025-dbau1200/arch/mips/no-math-emu/Makefile 2005-09-06 09:13:54.000000000 +0200 @@ -0,0 +1,5 @@ +# +# Makefile for the Linux/MIPS kernel FPU emulation. +# + +obj-y := cp1emu.o kernel_linkage.o dsemul.o --=-AZcuWd0hzG6Kj7KQhnEu-- From ralf@linux-mips.org Wed Nov 30 11:20:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 11:20:41 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:12563 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133460AbVK3LUY (ORCPT ); Wed, 30 Nov 2005 11:20:24 +0000 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 jAUBNkwq004404; Wed, 30 Nov 2005 11:23:46 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAUBNiL2004403; Wed, 30 Nov 2005 11:23:44 GMT Date: Wed, 30 Nov 2005 11:23:44 +0000 From: Ralf Baechle To: Matej Kupljen Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix board type in db1x00 Message-ID: <20051130112344.GA2694@linux-mips.org> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <20051129165148.GA20402@linux-mips.org> <1133339727.24526.11.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1133339727.24526.11.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9564 X-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: 339 Lines: 11 On Wed, Nov 30, 2005 at 09:35:27AM +0100, Matej Kupljen wrote: > > But we don't have a nice space for this in header files either right now. > > So I'll apply this one but if you come up with something better I'll > > certainly appreciate it. > > You forgot DBAU1200. Was not part of the patch posted. Can you cook up a patch? Ralf From ralf@linux-mips.org Wed Nov 30 11:28:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 11:28:19 +0000 (GMT) Received: from extgw-uk.mips.com ([62.254.210.129]:11526 "EHLO bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP id S8133833AbVK3L2C (ORCPT ); Wed, 30 Nov 2005 11:28:02 +0000 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 jAUBSM5E004564; Wed, 30 Nov 2005 11:28:22 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.4/8.13.4/Submit) id jAUBSLRJ004563; Wed, 30 Nov 2005 11:28:21 GMT Date: Wed, 30 Nov 2005 11:28:21 +0000 From: Ralf Baechle To: Matej Kupljen Cc: linux-mips@linux-mips.org, Jordan Crouse Subject: Re: MIPS no FP patch Message-ID: <20051130112821.GB2694@linux-mips.org> References: <1133348852.24526.31.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1133348852.24526.31.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9565 X-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: 552 Lines: 14 On Wed, Nov 30, 2005 at 12:07:32PM +0100, Matej Kupljen wrote: > This is a patch that makes FP emulation in kernel an option. > I used this when I was looking why there are still some > FP instruction in glibc, even though it was configured with > --withot-fp. This seemed the best way to ensure this. > > It is for the 2.6.14-rc2, but I think there is only a minimal > work to use it on latest kernel. We used to have this option but I eventually got rid of it because people just don't grok that they must enable it in precense of an FPU. Ralf From david.sanchez@lexbox.fr Wed Nov 30 13:19:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 13:19:36 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:27630 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133842AbVK3NTN convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 13:19:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: DbAu1550 copy file corruption X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 30 Nov 2005 14:18:58 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E027197@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DbAu1550 copy file corruption thread-index: AcX1lsl8tmWJBo5gSmGMP3cNVuA5+wAGXqEA From: "David Sanchez" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9566 X-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: 173 Lines: 11 Hi, I forgot to mention that I'm making my test on a ext2 filesystem... More can somebody launch the test on another Alchemy board ? Dbau1500, Dbau1200, etc... Thanks From david.sanchez@lexbox.fr Wed Nov 30 13:28:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 13:28:19 +0000 (GMT) Received: from laf31-5-82-235-130-100.fbx.proxad.net ([82.235.130.100]:11763 "EHLO lexbox.fr") by ftp.linux-mips.org with ESMTP id S8133842AbVK3N2C convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 13:28:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: DbAu1550 copy file corruption X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 30 Nov 2005 14:27:43 +0100 Message-ID: <17AB476A04B7C842887E0EB1F268111E027199@xpserver.intra.lexbox.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DbAu1550 copy file corruption thread-index: AcX1lsl8tmWJBo5gSmGMP3cNVuA5+wAGv+AA From: "David Sanchez" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9567 X-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: 2324 Lines: 109 Hi, I forgot to mention that I'm making my test on a ext2 filesystem... More can somebody launch the test on another Alchemy board ? Dbau1500, Dbau1200, etc... Thanks David -----Message d'origine----- De : David Sanchez Envoyé : mercredi 30 novembre 2005 11:14 À : 'linux-mips@linux-mips.org' Objet : DbAu1550 copy file corruption Hi, I still have a problem of file corruption after a big copy (around 300M) and no solution at this time... Who have a dbau1550 and who could try the following script to check copies on big files? #################################### #!/bin/sh path_file=$1 if test -z $path_file ; then path_file=`pwd` fi # You can modify the source and the destination filename, the source file # size and the number of iterations. # Source and destination filename src_file=${path_file}/src_test_file dst_file=${path_file}/dst_test_file # Source file size: 300M src_file_size=300000 # Number of iterations let max_it=50 # Create source file if test ! -f ${src_file} ; then echo "* Generating ${src_file}..." dd bs=1024 count=${src_file_size} if=/dev/urandom of=${src_file} echo "" fi # Check if source exists if test -f ${src_file} ; then echo "* Check copy from $src_file to $dst_file:" echo "" else echo "$src_file does NOT exist" ; exec false fi # Clear destination if test -f ${dst_file} ; then rm ${dst_file} fi # Go let i=0 let nb_err=0 while [ $i -lt $max_it ] do cp ${src_file} ${dst_file} cmp ${src_file} ${dst_file} if [ $? -eq 0 ] then echo ${src_file} ${dst_file} IDENTICAL else let nb_err=nb_err+1 fi rm ${dst_file} let i=i+1 done # Result echo "" echo "Done" echo -e "\t$nb_err error(s) over $max_it iteration(s)" echo "" #################################### On my DbAu155 + Sata HDD on PDC20579 + Linux Kernel 2.6.10 + busybox 1.0: Each destination differs from the source: #################################### * Generating ./src_test_file... 300000+0 records in 300000+0 records out * Check copy from ./src_test_file to ./dst_test_file: ./src_test_file ./dst_test_file differ: char 10388254, line 40877 ./src_test_file ./dst_test_file differ: char 69932960, line 274140 ./src_test_file ./dst_test_file differ: char 36867840, line 144723 ... Done 50 error(s) over 50 iteration(s) #################################### Thanks' David From jcrouse@cosmic.amd.com Wed Nov 30 15:19:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 15:19:34 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:21402 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133439AbVK3PTN (ORCPT ); Wed, 30 Nov 2005 15:19:13 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id jAUFMYfj028965; Wed, 30 Nov 2005 07:22:35 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Wed, 30 Nov 2005 07:22:24 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id jAUFM4xc016304; Wed, 30 Nov 2005 07:22:04 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 410C52026; Wed, 30 Nov 2005 08:22:04 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id jAUFTHvJ008602; Wed, 30 Nov 2005 08:29:17 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id jAUFTGLf008601; Wed, 30 Nov 2005 08:29:16 -0700 Date: Wed, 30 Nov 2005 08:29:16 -0700 From: "Jordan Crouse" To: "Matej Kupljen" cc: "Ralf Baechle" , linux-mips@linux-mips.org Subject: Re: Fix board type in db1x00 Message-ID: <20051130152916.GI24825@cosmic.amd.com> References: <20051122221526.GZ18119@cosmic.amd.com> <6dabaec28e238ccc915f20f51ee28327@embeddedalley.com> <20051129165148.GA20402@linux-mips.org> <1133339727.24526.11.camel@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <1133339727.24526.11.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-WSS-ID: 6F931C3A3TS346126-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9568 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 310 Lines: 13 > You forgot DBAU1200. Nope. PB1200 and DB1200 boards do not compile au1000/db1x00/init.c they use au1000/pb1200/init.c instead, and said file already has the correct machine type. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From dan@embeddedalley.com Wed Nov 30 17:15:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 17:16:19 +0000 (GMT) Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]:41334 "HELO smtp102.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8133839AbVK3RP5 (ORCPT ); Wed, 30 Nov 2005 17:15:57 +0000 Received: (qmail 94018 invoked from network); 30 Nov 2005 16:27:01 -0000 Received: from unknown (HELO ?10.1.7.13?) (dan@embeddedalley.com@12.6.244.2 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 30 Nov 2005 16:27:01 -0000 In-Reply-To: <17AB476A04B7C842887E0EB1F268111E027190@xpserver.intra.lexbox.org> References: <17AB476A04B7C842887E0EB1F268111E027190@xpserver.intra.lexbox.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Dan Malek Subject: Re: DbAu1550 copy file corruption Date: Wed, 30 Nov 2005 11:27:16 -0500 To: "David Sanchez" X-Mailer: Apple Mail (2.623) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9569 X-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: 374 Lines: 14 On Nov 30, 2005, at 5:14 AM, David Sanchez wrote: > On my DbAu155 + Sata HDD on PDC20579 + Linux Kernel 2.6.10 + busybox Are you sure your disk interface is working properly? Have you tested this on an NFS partition? Does the on-board HPT371 work? I know the latter two used to work, but I don't remember testing a 2.6.10 kernel, I've been using newer ones. -- Dan From sshtylyov@ru.mvista.com Wed Nov 30 17:29:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Nov 2005 17:30:08 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:52352 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133847AbVK3R3u (ORCPT ); Wed, 30 Nov 2005 17:29:50 +0000 Received: (qmail 20157 invoked from network); 30 Nov 2005 17:33:10 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 30 Nov 2005 17:33:10 -0000 Message-ID: <438DE2DC.2030500@ru.mvista.com> Date: Wed, 30 Nov 2005 20:35:24 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: DbAu1550 copy file corruption References: <17AB476A04B7C842887E0EB1F268111E027190@xpserver.intra.lexbox.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 661 Lines: 18 Hello. Dan Malek wrote: > Have you tested this on an NFS partition? Does > the on-board HPT371 work? I know the latter two > used to work, but I don't remember testing a 2.6.10 > kernel, I've been using newer ones. Do you mean HPT371N? It shouldn't work (and does not work for us) since the current driver has severe clocking problems with anything but HPT370/374 on a 66 MHz PCI. So with the default 64 MHz Au1550 PCI clock the driver just locks up; it can only work if you plug in a 33 MHz PCI card to get Au1550 PCI clocked at 32 MHz. I was in the process of fixing this but this work is currently preempted by more urgent stuff... :-( WBR, Sergei