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 >= d