From ihollo@tom.com Thu Sep  1 04:07:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 04:07:47 +0100 (BST)
Received: from smtpr3.tom.com ([IPv6:::ffff:202.108.255.198]:61777 "HELO
	tom.com") by linux-mips.org with SMTP id <S8224808AbVIADHY>;
	Thu, 1 Sep 2005 04:07:24 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp3 (Coremail) with SMTP id QQA7EcxxFkNZACac.1
	for <linux-mips@linux-mips.org>; Thu, 01 Sep 2005 11:13:28 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <431671CF.8070906@tom.com>
Date:	Thu, 01 Sep 2005 11:13:19 +0800
From:	Zhuang Yuyao <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: [ADMtek 5120] 64M sdram on board but only 16M is deteted and usable
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ihollo@tom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8849
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ihollo@tom.com
Precedence: bulk
X-list: linux-mips

Hi,

I've just upgraded the SDRAM on my adm5120 board from 16M to 64M, but 
while the board is booting, it still reports that only 16M sdram is 
availible.
Since I do not have the source code of the bootloader, is there any way 
to let the board to boot with 64M sdram, or should I change to another 
bootloader?

Thanks very much.

Here is the boot message.
Linux version 2.6.12 (root@debian) (gcc version 3.4.2) #28 Wed Aug 31 
20:51:01 MDT 2005
CPU revision is: 0001800b
ADM5120 board setup
Determined physical RAM map:
 memory: 00b0b000 @ 004f5000 (usable)
Built 1 zonelists
Kernel command line:
Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 8kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (19 instructions).
Synthesized TLB load handler fastpath (31 instructions).
Synthesized TLB store handler fastpath (31 instructions).
Synthesized TLB modify handler fastpath (30 instructions).
PID hash table entries: 128 (order: 7, 2048 bytes)
CPU clock: 175MHz
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 11136k/11308k available (2369k kernel code, 160k reserved, 375k 
data, 2004k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
System has PCI BIOS
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
ADM5120 LED & GPIO driver
ttyS0 at I/O 0x12600000 (irq = 1) is a ADM5120
ttyS1 at I/O 0x12800000 (irq = 2) is a ADM5120
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 7168K size 1024 blocksize
PPP generic driver version 2.4.2
NET: Registered protocol family 24
eth0: ADM5120 switch port0
eth1: ADM5120 switch port1
eth2: ADM5120 switch port2
eth3: ADM5120 switch port3
eth4: ADM5120 switch port4
eth5: ADM5120 switch port5
ADM5120 board flash (0x400000 at 0x1fc00000)
ADM5120: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 1 MTD partitions on "ADM5120":
0x003e0000-0x00400000 : "p1"
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
IPv4 over IPv4 tunneling driver
ip_conntrack version 2.1 (128 buckets, 1024 max) - 248 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.  
http://snowman.net/projects/ipt_recent/
ClusterIP Version 0.6 loaded successfully
arp_tables: (C) 2002 David S. Miller
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
Ebtables v2.0 registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Freeing unused kernel memory: 2101563k freed
Algorithmics/MIPS FPU Emulator v1.5
Mounting filesystems...

Please press Enter to activate this console.


While booted with pre-compiled image from 
http://sharon.esrac.ele.tue.nl/users/pe1rxq/linux-adm/vmlinuz-20050329.
The boot message looks like this (Still can not find the higher memory):

Linux version 2.6.12-rc1 (pe1rxq@laptop) (gcc version 3.4.2) #120 Mon 
Mar 28 01:10:40 CEST 2005
CPU revision is: 0001800b
ADM5120 board setup
System has PCI BIOS
Determined physical RAM map:
 memory: 00d1c000 @ 002e4000 (usable)
Built 1 zonelists
Kernel command line:
Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 8kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (19 instructions).
Synthesized TLB load handler fastpath (31 instructions).
Synthesized TLB store handler fastpath (31 instructions).
Synthesized TLB modify handler fastpath (30 instructions).
PID hash table entries: 128 (order: 7, 2048 bytes)
CPU clock: 175MHz
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 13244k/13424k available (1908k kernel code, 160k reserved, 315k 
data, 628k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing Cryptographic API
ADM5120 LED & GPIO driver
ttyS0 at I/O 0x12600000 (irq = 1) is a ADM5120
ttyS1 at I/O 0x12800000 (irq = 2) is a ADM5120
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: ADM5120 switch port0
eth1: ADM5120 switch port1
eth2: ADM5120 switch port2
eth3: ADM5120 switch port3
eth4: ADM5120 switch port4
eth5: ADM5120 switch port5
ADM5120 board flash (0x200000 at 0x1fc00000)
ADM5120: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
adm5120-hcd adm5120-hcd: new USB bus registered, assigned bus number 1
usb usb1: Product: adm5120-hcd
usb usb1: Manufacturer: Linux 2.6.12-rc1 adm5120-hcd
usb usb1: SerialNumber: adm5120-hcd
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
NET: Registered protocol family 17
Freeing unused kernel memory: 2099720k freed
Algorithmics/MIPS FPU Emulator v1.5
Relaxen und vatch das blinkenlights!!!
Mounting filesystems...

*********************************
 Its alive!!!!!!!!!!!!!!!!!!!!!!
*********************************



From yyuasa@gmail.com Thu Sep  1 04:25:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 04:25:55 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.194]:47371 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8224859AbVIADZg> convert rfc822-to-8bit;
	Thu, 1 Sep 2005 04:25:36 +0100
Received: by zproxy.gmail.com with SMTP id 13so190823nzn
        for <linux-mips@linux-mips.org>; Wed, 31 Aug 2005 20:31:46 -0700 (PDT)
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=cPf7z3qpLhbw7v+LvUUcuJ3hH6EB0kNezpWQP3WRxL5+AjV0MCttDYAkX2lleQ3abgg5SJtbzurU/HY5BlxwwivMQuA3tt5hFMVTUzczMi1+jJx76ZvT+k3os6AVfM2RM0U9qDT97vHQuMyn+/bHJ4v90xARIxKvG4MoRA275NY=
Received: by 10.36.80.12 with SMTP id d12mr1266653nzb;
        Wed, 31 Aug 2005 20:31:46 -0700 (PDT)
Received: by 10.36.59.12 with HTTP; Wed, 31 Aug 2005 20:31:46 -0700 (PDT)
Message-ID: <4955666b050831203143785a7f@mail.gmail.com>
Date:	Thu, 1 Sep 2005 12:31:46 +0900
From:	Yoichi Yuasa <yyuasa@gmail.com>
To:	Zhuang Yuyao <ihollo@tom.com>
Subject: Re: [ADMtek 5120] 64M sdram on board but only 16M is deteted and usable
Cc:	linux-mips@linux-mips.org
In-Reply-To: <431671CF.8070906@tom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <431671CF.8070906@tom.com>
Return-Path: <yyuasa@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8850
X-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,

2005/9/1, Zhuang Yuyao <ihollo@tom.com>:
> Hi,
> 
> I've just upgraded the SDRAM on my adm5120 board from 16M to 64M, but
> while the board is booting, it still reports that only 16M sdram is
> availible.
> Since I do not have the source code of the bootloader, is there any way
> to let the board to boot with 64M sdram, or should I change to another
> bootloader?

If you are using add_memory_region() with fixed memory size,
you should change the value of it.

Yoichi

From ihollo@tom.com Thu Sep  1 06:16:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 06:17:05 +0100 (BST)
Received: from smtpr4.tom.com ([IPv6:::ffff:202.108.252.134]:23952 "HELO
	tom.com") by linux-mips.org with SMTP id <S8225377AbVIAFQm>;
	Thu, 1 Sep 2005 06:16:42 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp14 (Coremail) with SMTP id JAD1ViWQFkNKACac.1
	for <yyuasa@gmail.com>; Thu, 01 Sep 2005 13:22:49 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <43169027.8060102@tom.com>
Date:	Thu, 01 Sep 2005 13:22:47 +0800
From:	Zhuang Yuyao <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Yoichi Yuasa <yyuasa@gmail.com>, linux-mips@linux-mips.org
Subject: Re: [ADMtek 5120] 64M sdram on board but only 16M is deteted and
 usable
References: <431671CF.8070906@tom.com> <4955666b050831203143785a7f@mail.gmail.com>
In-Reply-To: <4955666b050831203143785a7f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ihollo@tom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8851
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ihollo@tom.com
Precedence: bulk
X-list: linux-mips

Hi,

No, I am not using fixed memory size.

The original source code (part) in arch/mips/adm5120/memory.c is:
......
#define ADM5120_MEMCTRL                 0x1200001c
#define ADM5120_MEMCTRL_SDRAM_MASK      0x7

static const unsigned long adm_sdramsize[] __initdata = {
        0x0,            /* Reserved */
        0x0400000,      /* 4Mb */
        0x0800000,      /* 8Mb */
        0x1000000,      /* 16Mb */
        0x4000000,      /* 64Mb */
        0x8000000,      /* 128Mb */
};

void __init prom_meminit(void)
{
        unsigned long base=CPHYSADDR(PFN_ALIGN(&_end));
        unsigned long size;

        u32 memctrl = *(u32*)KSEG1ADDR(ADM5120_MEMCTRL);
        size = adm_sdramsize[memctrl & ADM5120_MEMCTRL_SDRAM_MASK];
         add_memory_region(base, size-base, BOOT_MEM_RAM);
}
......

memctrl value returns 0x50403 even though the actual memory size is 64M.

Then I tried to manually set KSEG1ADDR(ADM5120_MEMCTRL) to 0x50404 by 
inserting the following lines into prom_meminit(void).

        unsigned long size;

+      u32* pm = (u32*)KSEG1ADDR(ADM5120_MEMCTRL);
+      *pm = (*pm & ~ADM5120_MEMCTRL_SDRAM_MASK) + 0x4;

        u32 memctrl = *(u32*)KSEG1ADDR(ADM5120_MEMCTRL);

memctrl value returns 0x50404, the boot is failed but many messages 
printed to the console:

**********************************************************************
                            Linux Boot Loader


Copyright 2002-2003  ADMtek, Inc.



CPU: ADM5120 Home Gateway Processor
Boot Loader Version: 2.00.0125
Creation Date: 2003.07.09

Linux version 2.6.12 (root@debian) (gcc version 3.4.2) #36 Wed Aug 31 
22:52:06 MDT 2005
memctrl: 50404
CPU revision is: 0001800b
ADM5120 board setup
Determined physical RAM map:
 memory: 03b0b000 @ 004f5000 (usable)
Built 1 zonelists
Kernel command line:
Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 8kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (19 instructions).
Synthesized TLB load handler fastpath (31 instructions).
Synthesized TLB store handler fastpath (31 instructions).
Synthesized TLB modify handler fastpath (30 instructions).
PID hash table entries: 512 (order: 9, 8192 bytes)
CPU clock: 175MHz
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 59776k/60460k available (2369k kernel code, 624k reserved, 375k 
data, 2004k init, 0k highmem)
Mount-cache hash table entries: 512
Data bus error, epc == 80108e50, ra == 8005c21c
Oops in arch/mips/kernel/traps.c::do_be, line 354[#1]:
Cpu 0
$ 0   : 00000000 10008c00 804fb410 8c8506e4
$ 4   : 804fb410 b31e0620 00000040 ffffffff
$ 8   : 00000002 00000000 00000000 804b0000
$12   : 80288214 00100100 00200200 804fc8f4
$16   : 804fb400 804fc960 804fc96c 8109eac0
$20   : 804b0000 00000000 000000d0 11110017
$24   : 00000000 80283de2                 
$28   : 80282000 80283e28 80ee1da0 8005c21c
Hi    : 00000000
Lo    : 00000ea0
epc   : 80108e50 both_aligned+0x10/0x64     Not tainted
ra    : 8005c21c cache_alloc_refill+0x254/0x690
Status: 10008c02    KERNEL EXL
Cause : 3080001c
PrId  : 0001800b
Modules linked in:
Process swapper (pid: 0, threadinfo=80282000, task=80284000)
Stack : 0000000d 804b0000 10008c01 000041ed 804fb000 800c2130 10008c01 
804f7ed4
        00000000 80255da0 804b0000 00000000 11110016 11110017 80ee1da0 
8005bc60
        804fb000 8009fffc 804fc86c 00000000 00000000 8009e67c 804fb000 
000041ed
        00000000 800a0814 00000000 804f7ed4 80000000 800c2130 00000000 
8009e924
        00000000 800849d4 8028994c 8025e89c 804f7ed4 804fb000 800c21a8 
800c2190
        ...
Call Trace:
 [<800c2130>] ramfs_fill_super+0x0/0xac
 [<8005bc60>] kmem_cache_alloc+0x94/0x9c
 [<8009fffc>] alloc_inode+0x11c/0x144
 [<8009e67c>] d_alloc+0x34/0x228
 [<800a0814>] new_inode+0x14/0x8c
 [<800c2130>] ramfs_fill_super+0x0/0xac
 [<8009e924>] d_alloc_root+0x30/0x68
 [<800849d4>] sget+0x324/0x3ac
 [<800c21a8>] ramfs_fill_super+0x78/0xac
 [<800c2190>] ramfs_fill_super+0x60/0xac
 [<800c2130>] ramfs_fill_super+0x0/0xac
 [<800859b0>] get_sb_nodev+0x84/0xdc
 [<800a31a8>] alloc_vfsmnt+0xa8/0xe8
 [<8005ddcc>] kmem_cache_create+0x770/0x7c4
 [<80085b54>] do_kern_mount+0x68/0x1b0
 [<802c58f0>] mnt_init+0xe4/0x280
 [<802c5848>] mnt_init+0x3c/0x280
 [<802c575c>] inode_init+0x4c/0xfc
 [<802c5538>] vfs_caches_init+0x100/0x1d0
 [<802c5528>] vfs_caches_init+0xf0/0x1d0
 [<800f88c0>] key_link+0x40/0x5c
 [<802b17c8>] start_kernel+0x1e8/0x260
 [<802b17c0>] start_kernel+0x1e0/0x260
 [<802b112c>] unknown_bootoption+0x0/0x310


Code: 11000017  30d8001f  00000000 <8ca80000> 8ca90004  8caa0008  
8cab000c  24c6ffe0  8cac0010
Kernel panic - not syncing: Attempted to kill the idle task!

******************************************************************

Any suggestions will be appreciated!

Yoichi Yuasa wrote:

>Hi,
>
>2005/9/1, Zhuang Yuyao <ihollo@tom.com>:
>  
>
>>Hi,
>>
>>I've just upgraded the SDRAM on my adm5120 board from 16M to 64M, but
>>while the board is booting, it still reports that only 16M sdram is
>>availible.
>>Since I do not have the source code of the bootloader, is there any way
>>to let the board to boot with 64M sdram, or should I change to another
>>bootloader?
>>    
>>
>
>If you are using add_memory_region() with fixed memory size,
>you should change the value of it.
>
>Yoichi
>
>
>  
>



From matej.kupljen@ultra.si Thu Sep  1 07:58:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 07:58:58 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:15271 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225393AbVIAG6k>; Thu, 1 Sep 2005 07:58:40 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id F2E48C019
	for <linux-mips@linux-mips.org>; Thu,  1 Sep 2005 09:04:45 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id EEB571BC07B
	for <linux-mips@linux-mips.org>; Thu,  1 Sep 2005 09:04:46 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.168])
	by smtp.triera.net (Postfix) with ESMTP id A2A7C1A18AD
	for <linux-mips@linux-mips.org>; Thu,  1 Sep 2005 09:04:46 +0200 (CEST)
Subject: DBAU1200 network performacne
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	linux-mips@linux-mips.org
Content-Type: text/plain
Date:	Thu, 01 Sep 2005 09:03:11 +0200
Message-Id: <1125558191.6063.17.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8852
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips

Hi

I am working on DBAu1200 platform and I am testing network
performance with the smc91111 driver from AMD and smc91x
driver, which should be preferred (right?).

Tests are done on kernel 2.6.11-rc5 with the netperf,
running netserver on target and netperf on host.
If I run netserver on host and netperf on target, I get:
------------------------------------------------------------------------
recv_response: partial response received: 0 bytes

What does that mean?

OK, the results:

1) With the smc91111 I get:
------------------------------------------------------------------------
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to xxx.xxx.xxx.xxx
(xxx.xxx.xxx.xxx) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 43689  16384  16384    30.02      20.95   


2) With the smc91x I get:
------------------------------------------------------------------------
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to xxx.xxx.xxx.xxx
(xxx.xxx.xxx.xxx) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 43689  16384  16384    30.01      27.61   


Is this expected trough-put?
Can somebody else test it, please?

Oh, when using smc91x I get:
eth0: link down
Sending BOOTP requests .<6>eth0: link up, 100Mbps, full-duplex, lpa
0x4DE1

So, link should be 100Mbps.

BR,
Matej


From ths@networkno.de Thu Sep  1 09:27:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 09:27:42 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:19915 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8225327AbVIAI1X>;
	Thu, 1 Sep 2005 09:27:23 +0100
Received: from port-195-158-167-225.dynamic.qsc.de ([195.158.167.225] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1EAkVo-0002tP-00; Thu, 01 Sep 2005 10:33:32 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EAkVq-00019E-2F; Thu, 01 Sep 2005 10:33:34 +0200
Date:	Thu, 1 Sep 2005 10:33:34 +0200
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	ralf@linux-mips.org, geoman@gentoo.org, linux-mips@linux-mips.org
Subject: Re: compiling kernel 2.6.13
Message-ID: <20050901083333.GB26161@hattusa.textio>
References: <4315CD1C.80203@gentoo.org> <20050831153509.GF3377@linux-mips.org> <20050831155526.GW21717@hattusa.textio> <20050901.012247.36920050.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050901.012247.36920050.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8853
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips

Atsushi Nemoto wrote:
> >>>>> On Wed, 31 Aug 2005 17:55:26 +0200, Thiemo Seufer <ths@networkno.de> said:
> >> But that seems an IP22-specific problem.
> 
> ths> I _think_ it hits every 64bit kernel which uses mappings in
> ths> CKSEG0.  Do you know a system where this works?
> 
> Though I do not have IP22, I think this line in mach-ip22/space.h is
> inappropriate.
> 
> #define MAP_BASE		0xffffffffc0000000
> 
> It will make VMALLOC_END in pgtabe-64.h overflow.
> 
> #define VMALLOC_START		MAP_BASE
> #define VMALLOC_END	\
> 	(VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE)
> 
> Shoule we use 0xc000000000000000 as MAP_BASE for IP22 ?

Thanks, this helped!


Thiemo

From david.sanchez@lexbox.fr Thu Sep  1 10:03:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 10:03:48 +0100 (BST)
Received: from laf31-5-82-235-130-100.fbx.proxad.net ([IPv6:::ffff:82.235.130.100]:15847
	"EHLO lexbox.fr") by linux-mips.org with ESMTP id <S8225401AbVIAJD1> convert rfc822-to-8bit;
	Thu, 1 Sep 2005 10:03:27 +0100
Subject: How to detect stack overflow
Date:	Thu, 1 Sep 2005 11:06:39 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Message-ID: <17AB476A04B7C842887E0EB1F268111E026F2A@xpserver.intra.lexbox.org>
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
X-MS-TNEF-Correlator: 
Thread-Topic: How to detect stack overflow
thread-index: AcWu1HZ0Uc8uNGQeTP6WIUftjeMC5Q==
From:	"David Sanchez" <david.sanchez@lexbox.fr>
To:	<linux-mips@linux-mips.org>
Return-Path: <david.sanchez@lexbox.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8854
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: david.sanchez@lexbox.fr
Precedence: bulk
X-list: linux-mips

Hi,

I'm using the linux kernel 2.6.10 on an AMD dbau1550 thus with a mips32
cpu.

I'm wondering how to detect stack overflow. Does somebody know a patch
or something else to do such a work ?

Thanks

David


From ralf@linux-mips.org Thu Sep  1 12:12:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 12:12:42 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:59922 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225407AbVIALMU>; Thu, 1 Sep 2005 12:12:20 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j81BIatH006356;
	Thu, 1 Sep 2005 12:18:36 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j81BIas9006355;
	Thu, 1 Sep 2005 12:18:36 +0100
Date:	Thu, 1 Sep 2005 12:18:36 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Cc:	linux-cvs-patches@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050901111836.GD2876@linux-mips.org>
References: <20050901085634Z8225385-3678+8053@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050901085634Z8225385-3678+8053@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8855
X-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, Sep 01, 2005 at 09:56:30AM +0100, ths@linux-mips.org wrote:

> diff -urN linux/include/asm-mips/mach-ip22/spaces.h linux/include/asm-mips/mach-ip22/spaces.h
> --- linux/include/asm-mips/mach-ip22/spaces.h	2005/07/14 12:05:11	1.3
> +++ linux/include/asm-mips/mach-ip22/spaces.h	2005/09/01 08:56:18	1.4
> @@ -44,7 +44,7 @@
>  #define CAC_BASE		0xffffffff80000000
>  #define IO_BASE			0xffffffffa0000000
>  #define UNCAC_BASE		0xffffffffa0000000
> -#define MAP_BASE		0xffffffffc0000000
> +#define MAP_BASE		0xc000000000000000

You just broke the R5000.

  Ralf

From ralf@linux-mips.org Thu Sep  1 12:24:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 12:25:17 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:29717 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225546AbVIALYy>; Thu, 1 Sep 2005 12:24:54 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j81BVAYt006806
	for <linux-mips@linux-mips.org>; Thu, 1 Sep 2005 12:31:10 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j81BVAd6006805
	for linux-mips@linux-mips.org; Thu, 1 Sep 2005 12:31:10 +0100
Date:	Thu, 1 Sep 2005 12:31:10 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050901113110.GB5841@linux-mips.org>
References: <20050901085634Z8225385-3678+8053@linux-mips.org> <20050901111836.GD2876@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050901111836.GD2876@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8856
X-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, Sep 01, 2005 at 12:18:36PM +0100, Ralf Baechle wrote:

> You just broke the R5000.

Forgot it, was thinking of something else, the ll/sc in XKPHYS bug ...

  Ralf

From bryan.althouse@3phoenix.com Thu Sep  1 17:10:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 17:10:40 +0100 (BST)
Received: from rwcrmhc14.comcast.net ([IPv6:::ffff:204.127.198.54]:40396 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225398AbVIAQKX>; Thu, 1 Sep 2005 17:10:23 +0100
Received: from ba3pi (wsip-70-184-242-86.dc.dc.cox.net[70.184.242.86])
          by comcast.net (rwcrmhc14) with SMTP
          id <2005090116163801400e9lt7e>; Thu, 1 Sep 2005 16:16:39 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Ralf Baechle'" <ralf@linux-mips.org>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: custom ide driver causes "Badness in smp_call_function"
Date:	Thu, 1 Sep 2005 12:15:31 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcWqR/nIHNFE/tghSraa2RLTN9Py/gEUAOVw
In-Reply-To: <20050826141047.GA8777@linux-mips.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050901161023Z8225398-3678+8096@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8858
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1303
Lines: 46

Ralf,

I've done more testing with your patch.  When I use it with my non-SMP
kernel, disk access will cause a panic with a cache error message.  Is this
patch only intended for SMP, or is this a legitimate problem?

Bryan


Index: include/asm-mips/mach-generic/ide.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/mach-generic/ide.h,v
retrieving revision 1.9
diff -u -r1.9 ide.h
--- include/asm-mips/mach-generic/ide.h	19 Apr 2005 12:26:59 -0000	1.9
+++ include/asm-mips/mach-generic/ide.h	26 Aug 2005 14:04:38 -0000
@@ -19,6 +19,7 @@
 #include <linux/pci.h>
 #include <linux/stddef.h>
 #include <asm/processor.h>
+#include <asm/cacheflush.h>
 
 #ifndef MAX_HWIFS
 # ifdef CONFIG_BLK_DEV_IDEPCI
@@ -105,12 +106,14 @@
 
 /* MIPS port and memory-mapped I/O string operations.  */
 
-static inline void __ide_flush_dcache_range(unsigned long addr, unsigned
long size)
+static inline void __ide_flush_dcache_range(unsigned long addr,
+	unsigned long size)
 {
-	if (cpu_has_dc_aliases) {
-		unsigned long end = addr + size;
-		for (; addr < end; addr += PAGE_SIZE)
-			flush_dcache_page(virt_to_page(addr));
+	unsigned long end = addr + size;
+
+	while (addr < end) {
+		SetPageDcacheDirty(virt_to_page(addr));
+		addr += PAGE_SIZE;
 	}
 }
 


From ralf@linux-mips.org Thu Sep  1 17:46:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 17:46:43 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:6670 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225398AbVIAQq1>; Thu, 1 Sep 2005 17:46:27 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j81GqakJ017648;
	Thu, 1 Sep 2005 17:52:36 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j81GqZiN017647;
	Thu, 1 Sep 2005 17:52:35 +0100
Date:	Thu, 1 Sep 2005 17:52:35 +0100
From:	Ralf Baechle DL5RB <ralf@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: custom ide driver causes "Badness in smp_call_function"
Message-ID: <20050901165235.GI2876@linux-mips.org>
References: <20050826141047.GA8777@linux-mips.org> <20050901161023Z8225398-3678+8096@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050901161023Z8225398-3678+8096@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8859
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 438
Lines: 12

On Thu, Sep 01, 2005 at 12:15:31PM -0400, Bryan Althouse wrote:

> I've done more testing with your patch.  When I use it with my non-SMP
> kernel, disk access will cause a panic with a cache error message.  Is this
> patch only intended for SMP, or is this a legitimate problem?

There is a real problem but it only hits on SMP.

(The implementation is a hack though, it makes assumptions about the IDE
code's internal workings)

  Ralf

From tmnousia@twilight.cs.hut.fi Thu Sep  1 18:16:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 18:16:51 +0100 (BST)
Received: from twilight.cs.hut.fi ([IPv6:::ffff:130.233.40.5]:15843 "EHLO
	twilight.cs.hut.fi") by linux-mips.org with ESMTP
	id <S8225550AbVIARQd>; Thu, 1 Sep 2005 18:16:33 +0100
Received: by twilight.cs.hut.fi (Postfix, from userid 60001)
	id 35AD22DB3; Thu,  1 Sep 2005 20:22:50 +0300 (EEST)
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50])
	by twilight.cs.hut.fi (Postfix) with ESMTP id CD1D42DA1
	for <linux-mips@linux-mips.org>; Thu,  1 Sep 2005 20:22:49 +0300 (EEST)
Received: (from tmnousia@localhost)
	by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j81HMn904232;
	Thu, 1 Sep 2005 20:22:49 +0300 (EEST)
Date:	Thu, 1 Sep 2005 20:22:49 +0300 (EEST)
From:	turja@mbnet.fi
X-X-Sender: tmnousia@kekkonen.cs.hut.fi
Reply-To: turja@mbnet.fi
To:	linux-mips@linux-mips.org
Subject: [PATCH] SGI VINO Kconfig patch
Message-ID: <Pine.GSO.4.58.0509012016560.3961@kekkonen.cs.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <tmnousia@twilight.cs.hut.fi>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8860
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: turja@mbnet.fi
Precedence: bulk
X-list: linux-mips
Content-Length: 2379
Lines: 65

Please apply this patch to make the config for VINO a bit nicer :)

Mikael Nousiainen


diff -urN b/drivers/media/video/Kconfig c/drivers/media/video/Kconfig
--- b/drivers/media/video/Kconfig	2005-08-10 17:37:15.000000000 +0300
+++ c/drivers/media/video/Kconfig	2005-09-01 20:07:35.000000000 +0300
@@ -153,12 +153,38 @@
 	  If in doubt, say N.

 config VIDEO_VINO
-	tristate "SGI Vino Video For Linux (EXPERIMENTAL)"
-	depends on VIDEO_DEV && I2C && SGI_IP22 && EXPERIMENTAL
+	tristate "SGI VINO Video For Linux"
+	depends on VIDEO_DEV && I2C && SGI_IP22
 	select I2C_ALGO_SGI
 	help
-	  Say Y here to build in support for the Vino video input system found
-	  on SGI Indy machines.
+	  Say Y here to enable support for the VINO video input system found
+	  on SGI Indy machines. To use the driver you also need to select
+	  at least one of the video input modules: SAA7191 and IndyCam.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called vino.
+
+config VIDEO_SAA7191
+	tristate "Philips SAA7191 video decoder support"
+	depends on VIDEO_VINO
+	default y
+	help
+	  Say Y here to enable support for the Philips SAA7191 digital
+	  multi-standard video decoder. This driver provides access
+	  to the Composite and S-Video inputs of SGI Indy.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called saa7191.
+
+config VIDEO_INDYCAM
+	tristate "SGI IndyCam support"
+	depends on VIDEO_VINO
+	default y
+	help
+	  Say Y here to enable support for the SGI IndyCam digital camera.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called indycam.

 config VIDEO_STRADIS
 	tristate "Stradis 4:2:2 MPEG-2 video driver  (EXPERIMENTAL)"
diff -urN b/drivers/media/video/Makefile c/drivers/media/video/Makefile
--- b/drivers/media/video/Makefile	2005-08-16 16:32:52.000000000 +0300
+++ c/drivers/media/video/Makefile	2005-09-01 19:58:00.000000000 +0300
@@ -29,7 +29,9 @@
 obj-$(CONFIG_VIDEO_ZORAN) += zr36067.o videocodec.o
 obj-$(CONFIG_VIDEO_PMS) += pms.o
 obj-$(CONFIG_VIDEO_PLANB) += planb.o
-obj-$(CONFIG_VIDEO_VINO) += vino.o saa7191.o indycam.o
+obj-$(CONFIG_VIDEO_VINO) += vino.o
+obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
+obj-$(CONFIG_VIDEO_INDYCAM) += indycam.o
 obj-$(CONFIG_VIDEO_STRADIS) += stradis.o
 obj-$(CONFIG_VIDEO_CPIA) += cpia.o
 obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o

From nsauzede@online.fr Thu Sep  1 21:10:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Sep 2005 21:10:31 +0100 (BST)
Received: from postfix3-2.free.fr ([IPv6:::ffff:213.228.0.169]:54741 "EHLO
	postfix3-2.free.fr") by linux-mips.org with ESMTP
	id <S8224914AbVIAUKK>; Thu, 1 Sep 2005 21:10:10 +0100
Received: from home (vig38-1-82-67-77-237.fbx.proxad.net [82.67.77.237])
	by postfix3-2.free.fr (Postfix) with ESMTP id D6759C231
	for <linux-mips@linux-mips.org>; Thu,  1 Sep 2005 22:16:29 +0200 (CEST)
From:	Nicolas Sauzede <nsauzede@online.fr>
To:	linux-mips@linux-mips.org
Subject: Compiling 2.6.13 CVS on Indy R4K
Date:	Thu, 1 Sep 2005 22:16:24 +0200
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200509012216.25711.nsauzede@online.fr>
Return-Path: <nsauzede@online.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8861
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nsauzede@online.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 546
Lines: 16

... fails like this :

.........
  CC      arch/mips/kernel/module.o
  AS      arch/mips/kernel/r4k_fpu.o
  AS      arch/mips/kernel/r4k_switch.o
  CC      arch/mips/kernel/irq_cpu.o
{standard input}: Assembler messages:
{standard input}:231: Error: unrecognized opcode `ehb '
{standard input}:257: Error: unrecognized opcode `ehb '
{standard input}:305: Error: unrecognized opcode `ehb '
{standard input}:338: Error: unrecognized opcode `ehb '
make[1]: *** [arch/mips/kernel/irq_cpu.o] Error 1
make: *** [arch/mips/kernel] Error 2

Any ideas ??

From macro@linux-mips.org Fri Sep  2 12:28:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Sep 2005 12:28:48 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:59652 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224772AbVIBL22>; Fri, 2 Sep 2005 12:28:28 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 4BD9EE1CB1
	for <linux-mips@linux-mips.org>; Fri,  2 Sep 2005 13:34:51 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 30519-05 for <linux-mips@linux-mips.org>;
 Fri,  2 Sep 2005 13:34:51 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1EF2BE1C84
	for <linux-mips@linux-mips.org>; Fri,  2 Sep 2005 13:34:51 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j82BYrLj000506
	for <linux-mips@linux-mips.org>; Fri, 2 Sep 2005 13:34:53 +0200
Date:	Fri, 2 Sep 2005 12:35:00 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050902095417Z8224772-3678+8160@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0509021231390.19580@blysk.ds.pg.gda.pl>
References: <20050902095417Z8224772-3678+8160@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1053/Fri Sep  2 09:01:53 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8862
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 283
Lines: 12

On Fri, 2 Sep 2005 ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/mm   : c-r4k.c 
> 
> Log message:
> 	Fix r4600 revision bitmask.

 This change is broken.  The new masked out value may match a 
MIPS32/MIPS64 architecture CPU.  What was wrong with the old mask?

  Maciej

From ths@networkno.de Fri Sep  2 12:55:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Sep 2005 12:55:18 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:34213 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8224772AbVIBLzB>;
	Fri, 2 Sep 2005 12:55:01 +0100
Received: from port-195-158-167-225.dynamic.qsc.de ([195.158.167.225] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1EBAEV-000675-00
	for linux-mips@linux-mips.org; Fri, 02 Sep 2005 14:01:23 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EBAEX-0007wi-9n
	for linux-mips@linux-mips.org; Fri, 02 Sep 2005 14:01:25 +0200
Date:	Fri, 2 Sep 2005 14:01:25 +0200
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050902120125.GC4751@hattusa.textio>
References: <20050902095417Z8224772-3678+8160@linux-mips.org> <Pine.LNX.4.61L.0509021231390.19580@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0509021231390.19580@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8863
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 423
Lines: 17

Maciej W. Rozycki wrote:
> On Fri, 2 Sep 2005 ths@linux-mips.org wrote:
> 
> > Modified files:
> > 	arch/mips/mm   : c-r4k.c 
> > 
> > Log message:
> > 	Fix r4600 revision bitmask.
> 
>  This change is broken.  The new masked out value may match a 
> MIPS32/MIPS64 architecture CPU.  What was wrong with the old mask?

Hm, I made it the same as is used in pg-r4k.c without looking up
the meaning of the high bits.


Thiemo

From anemo@mba.ocn.ne.jp Fri Sep  2 13:41:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Sep 2005 13:41:24 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:43782
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225325AbVIBMlB>; Fri, 2 Sep 2005 13:41:01 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 2 Sep 2005 12:49:03 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id B27D61FE03;
	Fri,  2 Sep 2005 21:48:59 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 9E5D41797B;
	Fri,  2 Sep 2005 21:48:59 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j82Cmxoj003054;
	Fri, 2 Sep 2005 21:48:59 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Fri, 02 Sep 2005 21:48:59 +0900 (JST)
Message-Id: <20050902.214859.122594668.nemoto@toshiba-tops.co.jp>
To:	ralf@linux-mips.org
Cc:	linux-mips@linux-mips.org
Subject: Re: custom ide driver causes "Badness in smp_call_function"
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050826141047.GA8777@linux-mips.org>
References: <20050825154249.GC2731@linux-mips.org>
	<20050825211218Z8225471-3678+7505@linux-mips.org>
	<20050826141047.GA8777@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8864
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 416
Lines: 12

>>>>> On Fri, 26 Aug 2005 15:10:47 +0100, Ralf Baechle <ralf@linux-mips.org> said:
ralf> Try this patch below and let me know.  I would also like to ask
ralf> those people who used to suffer from aliases with IDE PIO to try
ralf> this patch.

I'm using CPU which suffer from dcache aliasing.
I tried this patch for IDE PIO and it seems work fine too.

Maybe Cobalt user can try it.  Anyone?  :-)

---
Atsushi Nemoto

From macro@linux-mips.org Fri Sep  2 14:23:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Sep 2005 14:23:48 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:58632 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225348AbVIBNXc>; Fri, 2 Sep 2005 14:23:32 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 8A77DE1C8E; Fri,  2 Sep 2005 15:29:55 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 10539-07; Fri,  2 Sep 2005 15:29:55 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 54F91E1C7B; Fri,  2 Sep 2005 15:29:55 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j82DTwIt004015;
	Fri, 2 Sep 2005 15:29:58 +0200
Date:	Fri, 2 Sep 2005 14:30:06 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050902120125.GC4751@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0509021428340.19580@blysk.ds.pg.gda.pl>
References: <20050902095417Z8224772-3678+8160@linux-mips.org>
 <Pine.LNX.4.61L.0509021231390.19580@blysk.ds.pg.gda.pl>
 <20050902120125.GC4751@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1053/Fri Sep  2 09:01:53 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8865
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 220
Lines: 8

On Fri, 2 Sep 2005, Thiemo Seufer wrote:

> Hm, I made it the same as is used in pg-r4k.c without looking up
> the meaning of the high bits.

 You have picked up the wrong variation. ;-)  Thanks for fixing up.

  Maciej

From maxim@kde.ru Sat Sep  3 03:25:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Sep 2005 03:25:37 +0100 (BST)
Received: from webadmin.ru ([IPv6:::ffff:212.119.32.46]:54022 "EHLO
	mail.webadmin.ru") by linux-mips.org with ESMTP id <S8225601AbVICCZU>;
	Sat, 3 Sep 2005 03:25:20 +0100
Received: (qmail 80088 invoked by uid 89); 3 Sep 2005 02:31:44 -0000
Received: from localhost (HELO ?192.168.1.143?) (maxim@kde.ru@127.0.0.1)
  by localhost with SMTP; 3 Sep 2005 02:31:44 -0000
Message-ID: <43190B15.7080301@kde.ru>
Date:	Sat, 03 Sep 2005 06:31:49 +0400
From:	Maxim Moroz <maxim@kde.ru>
User-Agent: Mozilla Thunderbird 1.0.6-1.1am (X11/20050721)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: framebuffer for au1000 based board.
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <maxim@kde.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8866
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim@kde.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 2570
Lines: 90

Hello, I'm writing framebuffer (800x600@16bpp) for au1000 based board 
for latest linux-2.6.13 mips kernel.
video memory is located at address 0xbe00_0000.
The problem is that I cannot correctly mmap video memory to userspace.

mmap was taken from au1500 lcd framebuffer driver(code follows)

start, fbi->fix.smem_start, off are all equal to 0xbe00_0000 (video 
memory start)

mmaping from userspace is working ok, but writing to mmaped memory gives 
no result
on display.

code like memset(0xbe00_0000,0,FB_MEM_SIZE) from kernel space is working 
as expected.

from userspace running test on mmaped fb gives no visible results.

cat /proc/156/maps
00400000-00407000 r-xp 00000000 08:01 27785      /root/fbtest
00446000-00447000 rw-p 00006000 08:01 27785      /root/fbtest
00447000-00449000 rwxp 00447000 00:00 0          [heap]
2aaa8000-2ab93000 rw-s be000000 08:01 17858      /dev/fb0
7fb12000-7fb27000 rwxp 7fb12000 00:00 0          [stack]

Also I have problems with ioremapping:
  //info->screen_base = ioremap(AU1000VLFB_BASE_PHYS, 
AU1000VLFB_FB_LEN); // <-doesn't work when do 'dd if=/dev/zero 
of=/dev/fb0 count=2048'
  info->screen_base = AU1000VLFB_BASE_PHYS; // <- this one clears screen 
when 'dd if=/dev/zero of=/dev/fb0 count=2048'

ioremap gives me 0xc000_0000 from 0xbe00_0000. I'm not sure if this  
correct.

Can't resolve problem myself.
Thank you in advance!
Best Regards, Maxim Moroz.
---------------------------------------

/* fb_mmap
 * Map video memory in user space. We don't use the generic fb_mmap 
method mainly
 * to allow the use of the TLB streaming flag (CCA=6)
 */
int au1000fb_fb_mmap(struct fb_info *fbi, struct file *file, struct 
vm_area_struct *vma)
{
  unsigned int len;
  unsigned long start=0, off;

  if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT)) {
    return -EINVAL;
  }

  start = fbi->fix.smem_start & PAGE_MASK;
  len = PAGE_ALIGN((start & ~PAGE_MASK) + fbi->fix.smem_len);

  off = vma->vm_pgoff << PAGE_SHIFT;

  if ((vma->vm_end - vma->vm_start + off) > len) {
    return -EINVAL;
  }

  off += start;
  vma->vm_pgoff = off >> PAGE_SHIFT;

  vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
  pgprot_val(vma->vm_page_prot) |= (6 << 9); //CCA=6

  vma->vm_flags |= VM_IO;

  printk("%lu %lu %lu %lu %lu\n",
          fbi->fix.smem_start,
          start,
          off,
          vma->vm_start,
          vma->vm_end - vma->vm_start
          );

  if (remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
        vma->vm_end - vma->vm_start,
        vma->vm_page_prot)) {
    return -EAGAIN;
  }

  return 0;
}


From dan@embeddedalley.com Sat Sep  3 04:59:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Sep 2005 04:59:31 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:62735 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8224989AbVICD7D>; Sat, 3 Sep 2005 04:59:03 +0100
Received: from [192.168.2.27] (h69-21-252-132.69-21.unk.tds.net [69.21.252.132])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j833k0KW026454;
	Fri, 2 Sep 2005 23:46:00 -0400
In-Reply-To: <43190B15.7080301@kde.ru>
References: <43190B15.7080301@kde.ru>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <e603bacb50427983d7330a58abccb4fa@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: framebuffer for au1000 based board.
Date:	Sat, 3 Sep 2005 00:05:11 -0400
To:	Maxim Moroz <maxim@kde.ru>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8867
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1103
Lines: 28


On Sep 2, 2005, at 10:31 PM, Maxim Moroz wrote:

> Hello, I'm writing framebuffer (800x600@16bpp) for au1000 based board 
> for latest linux-2.6.13 mips kernel.
> video memory is located at address 0xbe00_0000.
> The problem is that I cannot correctly mmap video memory to userspace.

What happens if you just use /dev/mem and that address?

> mmap was taken from au1500 lcd framebuffer driver(code follows)

Bad choice.  Neither the Au1000 nor the Au1500 have internal frame
buffers, so in both cases these are going to be board specific devices.
Since the Au1500 has a PCI bridge, I suspect that driver is designed
to work with the 36-bit address from the Au1500 core.  You are going
to have to write a custom mmap() function that does the proper mapping
for your board design.  Also, the Au1000 had some challenging bus
interface issues to things like graphics controllers and you have to
choose the proper memory controller configuration and hardware
design to even have a chance at this working.

Good Luck, you may have lots of work ahead of you very specific
to your board design :-)


	-- Dan


From maxim@kde.ru Sat Sep  3 05:09:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Sep 2005 05:09:48 +0100 (BST)
Received: from webadmin.ru ([IPv6:::ffff:212.119.32.46]:52235 "EHLO
	mail.webadmin.ru") by linux-mips.org with ESMTP id <S8224981AbVICEJc>;
	Sat, 3 Sep 2005 05:09:32 +0100
Received: (qmail 95432 invoked by uid 89); 3 Sep 2005 04:16:00 -0000
Received: from localhost (HELO ?192.168.1.143?) (maxim@kde.ru@127.0.0.1)
  by localhost with SMTP; 3 Sep 2005 04:15:59 -0000
Message-ID: <43192384.6010308@kde.ru>
Date:	Sat, 03 Sep 2005 08:16:04 +0400
From:	Maxim Moroz <maxim@kde.ru>
User-Agent: Mozilla Thunderbird 1.0.6-1.1am (X11/20050721)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: framebuffer for au1000 based board.
References: <43190B15.7080301@kde.ru> <e603bacb50427983d7330a58abccb4fa@embeddedalley.com>
In-Reply-To: <e603bacb50427983d7330a58abccb4fa@embeddedalley.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <maxim@kde.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8868
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maxim@kde.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 1539
Lines: 44

Dan Malek пишет:

>
> On Sep 2, 2005, at 10:31 PM, Maxim Moroz wrote:
>
>> Hello, I'm writing framebuffer (800x600@16bpp) for au1000 based board 
>> for latest linux-2.6.13 mips kernel.
>> video memory is located at address 0xbe00_0000.
>> The problem is that I cannot correctly mmap video memory to userspace.
>
>
> What happens if you just use /dev/mem and that address?
>
>> mmap was taken from au1500 lcd framebuffer driver(code follows)
>
>
> Bad choice. Neither the Au1000 nor the Au1500 have internal frame
> buffers, so in both cases these are going to be board specific devices.
> Since the Au1500 has a PCI bridge, I suspect that driver is designed
> to work with the 36-bit address from the Au1500 core. You are going
> to have to write a custom mmap() function that does the proper mapping
> for your board design. Also, the Au1000 had some challenging bus
> interface issues to things like graphics controllers and you have to
> choose the proper memory controller configuration and hardware
> design to even have a chance at this working.
>
> Good Luck, you may have lots of work ahead of you very specific
> to your board design :-)
>
>
> -- Dan

The choice is not bad. au1000 also has 36 bit addresses.
I was toooooo bad using address 0xbe00_0000.
changed to 0x1e00_0000 and got working video.
Thanks all who made such perfect port to au1x00 processors!
Really pleased to work with them... Heh.. Tried blackfin some time ago.
that was horrible :-D

He-he, board is almost working already.

Best Regards,
Maxim Moroz.


From ppopov@embeddedalley.com Sat Sep  3 05:48:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Sep 2005 05:48:53 +0100 (BST)
Received: from smtp102.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.237]:63843
	"HELO smtp102.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8224981AbVICEsh>; Sat, 3 Sep 2005 05:48:37 +0100
Received: (qmail 84210 invoked from network); 3 Sep 2005 04:55:01 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp102.biz.mail.mud.yahoo.com with SMTP; 3 Sep 2005 04:55:00 -0000
Subject: Re: framebuffer for au1000 based board.
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Maxim Moroz <maxim@kde.ru>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <43192384.6010308@kde.ru>
References: <43190B15.7080301@kde.ru>
	 <e603bacb50427983d7330a58abccb4fa@embeddedalley.com>
	 <43192384.6010308@kde.ru>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 02 Sep 2005 21:54:58 -0700
Message-Id: <1125723298.17941.129.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8869
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 408
Lines: 18


> The choice is not bad. au1000 also has 36 bit addresses.

The Au1500 doesn't have an internal video controller so I'm not sure
which fb driver you based your work on.

> I was toooooo bad using address 0xbe00_0000.
> changed to 0x1e00_0000 and got working video.

Ah, so you just had the physical address setup incorrectly.

> Thanks all who made such perfect port to au1x00 processors!

Enjoy :)

Pete



From ralf@linux-mips.org Mon Sep  5 00:22:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 00:22:36 +0100 (BST)
Received: from p549F6EE6.dip.t-dialin.net ([IPv6:::ffff:84.159.110.230]:46049
	"EHLO bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225352AbVIDXWQ>; Mon, 5 Sep 2005 00:22:16 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j84NSq16019092;
	Sun, 4 Sep 2005 23:28:52 GMT
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j84NSpAs019091;
	Sun, 4 Sep 2005 23:28:51 GMT
Date:	Sun, 4 Sep 2005 23:28:51 +0000
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Nicolas Sauzede <nsauzede@online.fr>
Cc:	linux-mips@linux-mips.org
Subject: Re: Compiling 2.6.13 CVS on Indy R4K
Message-ID: <20050904232851.GB3024@linux-mips.org>
References: <200509012216.25711.nsauzede@online.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200509012216.25711.nsauzede@online.fr>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8870
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 701
Lines: 22

On Thu, Sep 01, 2005 at 10:16:24PM +0200, Nicolas Sauzede wrote:

> ... fails like this :
> 
> .........
>   CC      arch/mips/kernel/module.o
>   AS      arch/mips/kernel/r4k_fpu.o
>   AS      arch/mips/kernel/r4k_switch.o
>   CC      arch/mips/kernel/irq_cpu.o
> {standard input}: Assembler messages:
> {standard input}:231: Error: unrecognized opcode `ehb '
> {standard input}:257: Error: unrecognized opcode `ehb '
> {standard input}:305: Error: unrecognized opcode `ehb '
> {standard input}:338: Error: unrecognized opcode `ehb '
> make[1]: *** [arch/mips/kernel/irq_cpu.o] Error 1
> make: *** [arch/mips/kernel] Error 2
> 
> Any ideas ??

You need binutils 2.16 to compile a CVS kernel.

  Ralf

From anemo@mba.ocn.ne.jp Mon Sep  5 05:46:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 05:46:27 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:52515
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224789AbVIEEqJ>; Mon, 5 Sep 2005 05:46:09 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Sep 2005 04:54:27 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id A56F91F5CF;
	Mon,  5 Sep 2005 13:54:23 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 980BF1EFA1;
	Mon,  5 Sep 2005 13:54:23 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j854sMoj013106;
	Mon, 5 Sep 2005 13:54:23 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Mon, 05 Sep 2005 13:54:22 +0900 (JST)
Message-Id: <20050905.135422.112260934.nemoto@toshiba-tops.co.jp>
To:	spodstavin@ru.mvista.com
Cc:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <1124355290.5441.45.camel@localhost.localdomain>
References: <1124355290.5441.45.camel@localhost.localdomain>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8871
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3118
Lines: 91

>>>>> On Thu, 18 Aug 2005 12:54:50 +0400, Sergey Podstavin <spodstavin@ru.mvista.com> said:
spodstavin> genrtc doesn't work as a module because functions for
spodstavin> module defined in wrong place. Most architectures define
spodstavin> these functions in <asm/rtc.h>, so make MIPS follow their
spodstavin> example.  It makes the generic MIPS RTC working as a
spodstavin> module for MIPS.

It seems this fix already checked in, but I have some comments.

1. There are unnecessary (and conflicting) prototype declarations.

2. Define static variable mips_rtc_lock in rtc.h is generally a bad
   idea.  There is already rtc_lock in arch/mips/kernel/time.h.

3. We should protect rtc_set_mmss() call during get_rtc_time or
   set_rtc_time (this is not your patch's fault).

How about this patch?  The rtc_lock could be manipulated in each
RTC-dependent routines, but I choose a simple way for now.

---
Atsushi Nemoto


diff -u linux-mips/include/asm-mips/rtc.h linux/include/asm-mips/rtc.h
--- linux-mips/include/asm-mips/rtc.h	2005-09-05 10:17:18.000000000 +0900
+++ linux/include/asm-mips/rtc.h	2005-09-05 13:32:51.000000000 +0900
@@ -29,23 +29,18 @@
 #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 */
 
-unsigned int get_rtc_time(struct rtc_time *time);
-int set_rtc_time(struct rtc_time *time);
-unsigned int get_rtc_ss(void);
-int get_rtc_pll(struct rtc_pll_info *pll);
-int set_rtc_pll(struct rtc_pll_info *pll);
-
-static DEFINE_SPINLOCK(mips_rtc_lock);
+extern spinlock_t rtc_lock;	/* in kernel/time.c */
 
 static inline unsigned int get_rtc_time(struct rtc_time *time)
 {
 	unsigned long nowtime;
+	unsigned long flags;
 
-	spin_lock(&mips_rtc_lock);
+	spin_lock_irqsave(&rtc_lock, flags);
 	nowtime = rtc_get_time();
 	to_tm(nowtime, time);
 	time->tm_year -= 1900;
-	spin_unlock(&mips_rtc_lock);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return RTC_24H;
 }
@@ -53,14 +48,15 @@
 static inline int set_rtc_time(struct rtc_time *time)
 {
 	unsigned long nowtime;
+	unsigned long flags;
 	int ret;
 
-	spin_lock(&mips_rtc_lock);
+	spin_lock_irqsave(&rtc_lock, flags);
 	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);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return ret;
 }
diff -u linux-mips/arch/mips/kernel/time.c linux/arch/mips/kernel/time.c
--- linux-mips/arch/mips/kernel/time.c	2005-08-30 11:02:01.000000000 +0900
+++ linux/arch/mips/kernel/time.c	2005-09-05 13:36:05.000000000 +0900
@@ -453,12 +453,14 @@
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    (xtime.tv_nsec / 1000) >= 500000 - ((unsigned) TICK_SIZE) / 2 &&
 	    (xtime.tv_nsec / 1000) <= 500000 + ((unsigned) TICK_SIZE) / 2) {
+		spin_lock(&rtc_lock);
 		if (rtc_set_mmss(xtime.tv_sec) == 0) {
 			last_rtc_update = xtime.tv_sec;
 		} else {
 			/* do it again in 60 s */
 			last_rtc_update = xtime.tv_sec - 600;
 		}
+		spin_unlock(&rtc_lock);
 	}
 	write_sequnlock(&xtime_lock);
 

From matej.kupljen@ultra.si Mon Sep  5 09:34:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 09:34:32 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:42438 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8224974AbVIEIeM>; Mon, 5 Sep 2005 09:34:12 +0100
Received: from localhost (in-3.mx.triera.net [213.161.0.27])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 69996C028;
	Mon,  5 Sep 2005 10:40:51 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-3.mx.triera.net (Postfix) with SMTP id E437D1BC089;
	Mon,  5 Sep 2005 10:40:52 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 9CA8C1A18B4;
	Mon,  5 Sep 2005 10:40:53 +0200 (CEST)
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	rolf liu <rolfliu@gmail.com>
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070609215b750fea@mail.gmail.com>
References: <2db32b720507011756247735d6@mail.gmail.com>
	 <1120266383.5987.46.camel@localhost.localdomain>
	 <2db32b72050705124078a48aed@mail.gmail.com>
	 <1120633817.5724.26.camel@localhost.localdomain>
	 <2db32b7205070609215b750fea@mail.gmail.com>
Content-Type: text/plain
Date:	Mon, 05 Sep 2005 10:40:54 +0200
Message-Id: <1125909654.19482.4.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8872
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 221
Lines: 11

Hi

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

Can we see the hack, please ? :-)

BR,
Matej


From robo@dare.nl Mon Sep  5 09:53:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 09:54:00 +0100 (BST)
Received: from post-23.mail.nl.demon.net ([IPv6:::ffff:194.159.73.193]:47331
	"EHLO post-23.mail.nl.demon.net") by linux-mips.org with ESMTP
	id <S8224976AbVIEIxm>; Mon, 5 Sep 2005 09:53:42 +0100
Received: from dare-holding.demon.nl ([212.238.232.25]:57035 helo=mouse.matrix.dare.nl)
	by post-23.mail.nl.demon.net with esmtp (Exim 4.51)
	id 1ECCq2-000CmJ-Ic
	for linux-mips@linux-mips.org; Mon, 05 Sep 2005 09:00:26 +0000
Received: from localhost (localhost [127.0.0.1])
	by mouse.matrix.dare.nl (Postfix) with ESMTP id C6A95E6311
	for <linux-mips@linux-mips.org>; Mon,  5 Sep 2005 11:00:38 +0200 (CEST)
Received: from mouse.matrix.dare.nl ([127.0.0.1])
	by localhost (mouse [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 18457-04 for <linux-mips@linux-mips.org>;
	Mon, 5 Sep 2005 11:00:38 +0200 (CEST)
Received: from [192.168.10.120] (id6220_10.matrix.dare.nl [192.168.10.120])
	by mouse.matrix.dare.nl (Postfix) with ESMTP id ECC22E6305
	for <linux-mips@linux-mips.org>; Mon,  5 Sep 2005 11:00:37 +0200 (CEST)
Message-ID: <431C0891.1070908@dare.nl>
Date:	Mon, 05 Sep 2005 10:57:53 +0200
From:	Robert Bon <robo@dare.nl>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050602)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Howto Boot from Flash with the Alchemy AU1100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: at dare.nl
Return-Path: <robo@dare.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8873
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: robo@dare.nl
Precedence: bulk
X-list: linux-mips
Content-Length: 320
Lines: 13

Hello,

We are running linux kernel 2.6.12 on a AMD-Alchemy DB1100 evaluation 
board, with processor AU1100.

De kernel file is a Srecord which is programmed (with the bootloader 
YAMON load command) in to RAM, starting at address 0x80100000.
We want to store in the onboard flash.

How can we do this?

Thanks Robert.


From macro@linux-mips.org Mon Sep  5 12:01:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 12:02:46 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:1039 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224976AbVIELBs>; Mon, 5 Sep 2005 12:01:48 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5182BE1D46; Mon,  5 Sep 2005 13:08:30 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 10307-02; Mon,  5 Sep 2005 13:08:30 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id BE153E1CBE; Mon,  5 Sep 2005 13:08:29 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j85B8R1R009479;
	Mon, 5 Sep 2005 13:08:28 +0200
Date:	Mon, 5 Sep 2005 12:08:34 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	spodstavin@ru.mvista.com, linux-mips@linux-mips.org,
	ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
In-Reply-To: <20050905.135422.112260934.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.LNX.4.61L.0509051204140.29615@blysk.ds.pg.gda.pl>
References: <1124355290.5441.45.camel@localhost.localdomain>
 <20050905.135422.112260934.nemoto@toshiba-tops.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1062/Sun Sep  4 09:55:30 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8874
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 530
Lines: 14

On Mon, 5 Sep 2005, Atsushi Nemoto wrote:

> 3. We should protect rtc_set_mmss() call during get_rtc_time or
>    set_rtc_time (this is not your patch's fault).
> 
> How about this patch?  The rtc_lock could be manipulated in each
> RTC-dependent routines, but I choose a simple way for now.

 That's how other architectures do this, see e.g. 
"arch/alpha/kernel/time.c".  Why should we be different, even for now?  
Also the call is named rtc_set_mmss() for an unknown reason while all the 
others have set_rtc_mmss().

  Maciej

From jh@hansen-telecom.dk Mon Sep  5 12:34:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 12:35:10 +0100 (BST)
Received: from smtp010.tiscali.dk ([IPv6:::ffff:212.54.64.103]:51646 "EHLO
	smtp010.tiscali.dk") by linux-mips.org with ESMTP
	id <S8224982AbVIELeu> convert rfc822-to-8bit; Mon, 5 Sep 2005 12:34:50 +0100
Received: from jorg ([62.79.30.245])
	by smtp010.tiscali.dk (8.12.10/8.12.10) with ESMTP id j85BfYnW009084
	for <linux-mips@linux-mips.org>; Mon, 5 Sep 2005 13:41:34 +0200 (MEST)
From:	=?iso-8859-1?Q?J=F8rg_Ulrich_Hansen?= <jh@hansen-telecom.dk>
To:	<linux-mips@linux-mips.org>
Subject: Re: Howto Boot from Flash with the Alchemy AU1100
Date:	Mon, 5 Sep 2005 13:41:34 +0200
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAb4ajDk58bkCNi0V1ZTQFHIKAAAAQAAAAS0TGHpU5zUWTXqf0fsiG9AEAAAAA@hansen-telecom.dk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcWyDsR7yEipV1BPSZWRu+EDn8ApGw==
Return-Path: <jh@hansen-telecom.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8875
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jh@hansen-telecom.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1639
Lines: 57


Start linux from flash at startup
The boot loader can be set up to automatically start Linux at power up.

Do the following:
To load kernel image into RAM on mb1100 type:
load

Then the image has to be copied to FLASH.
Erase block in FLASH:
erase bfd00000 2c0000

Copy image from RAM to FLASH:
copy a0100000 bfd00000 2c0000

When YAMON starts up it will process the start command, so that has to be
set up.
The kernel_entry address is not fixed so the start address has to be set up
for each new kernel
image. The start address can be read from the srec image file or it is
printed on the screen after
the load image command.

To set the start command:
set start 'copy bfd00000 a0100000 2c0000; go a032b018 \
root=/dev/mtdblock0 rootfstype=jffs2'


Start Linux with root file system mounted as jffs2
In a real world the root file system will normally be located in the FLASH
memory as a jffs2
partition. 
We will now copy a jffs2 image with the root file system to the FLASH.

From YAMON prompt do following:
Fill 16 MB of RAM with FF:
fill a1000000 1000000 ff
Load image into RAM:
load tftp://192.168.21.33/rootfs.srec
Erase 16MB in FLASH:
erase be000000 1000000
Copy 4MB from RAM to FLASH
copy a1000000 be000000 400000
If the image is bigger than 4MB please copy the appropriate size.

Now it should be ready to press reset.

If it prints a lot of text Linux starts correctly
If it prints ‘kernel panic’ in the end then it failed to mount the root file
system

This is based on a CPU module mb1100 that is similar to db1100.
More information about au1100 running Linux can be found at
http://www.mechatronicbrick.dk

Kind regards Jorg


From anemo@mba.ocn.ne.jp Mon Sep  5 14:37:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 14:38:03 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:55751 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225196AbVIENhp>; Mon, 5 Sep 2005 14:37:45 +0100
Received: from localhost (p2231-ipad28funabasi.chiba.ocn.ne.jp [220.107.201.231])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 7F7737C75; Mon,  5 Sep 2005 22:44:29 +0900 (JST)
Date:	Mon, 05 Sep 2005 22:45:34 +0900 (JST)
Message-Id: <20050905.224534.25910293.anemo@mba.ocn.ne.jp>
To:	macro@linux-mips.org
Cc:	spodstavin@ru.mvista.com, linux-mips@linux-mips.org,
	ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.LNX.4.61L.0509051204140.29615@blysk.ds.pg.gda.pl>
References: <1124355290.5441.45.camel@localhost.localdomain>
	<20050905.135422.112260934.nemoto@toshiba-tops.co.jp>
	<Pine.LNX.4.61L.0509051204140.29615@blysk.ds.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8876
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 653
Lines: 17

>>>>> On Mon, 5 Sep 2005 12:08:34 +0100 (BST), "Maciej W. Rozycki" <macro@linux-mips.org> said:

macro>  That's how other architectures do this, see e.g.
macro> "arch/alpha/kernel/time.c".  Why should we be different, even
macro> for now?

Please elaborate more ?  Do you mean we should implement default
rtc_set_mmss() and take the rtc_lock in it ?  Or do you mean we should
take rtc_lock in each board-dependent rtc_set_time/rtc_set_time ?  

macro> Also the call is named rtc_set_mmss() for an unknown reason
macro> while all the others have set_rtc_mmss().

IIRC, you are (one of) the godfather of the function, aren't you?  :-)

---
Atsushi Nemoto

From macro@linux-mips.org Mon Sep  5 16:18:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 16:18:57 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:10764 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225201AbVIEPSl>; Mon, 5 Sep 2005 16:18:41 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id D036CE1C91; Mon,  5 Sep 2005 17:25:23 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 08046-04; Mon,  5 Sep 2005 17:25:23 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 7931DE1CB5; Mon,  5 Sep 2005 17:25:23 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j85FPN0f018677;
	Mon, 5 Sep 2005 17:25:23 +0200
Date:	Mon, 5 Sep 2005 16:25:32 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	spodstavin@ru.mvista.com, linux-mips@linux-mips.org,
	ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
In-Reply-To: <20050905.224534.25910293.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.LNX.4.61L.0509051620020.29615@blysk.ds.pg.gda.pl>
References: <1124355290.5441.45.camel@localhost.localdomain>
 <20050905.135422.112260934.nemoto@toshiba-tops.co.jp>
 <Pine.LNX.4.61L.0509051204140.29615@blysk.ds.pg.gda.pl>
 <20050905.224534.25910293.anemo@mba.ocn.ne.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1063/Mon Sep  5 13:16:34 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8877
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 960
Lines: 24

On Mon, 5 Sep 2005, Atsushi Nemoto wrote:

> macro>  That's how other architectures do this, see e.g.
> macro> "arch/alpha/kernel/time.c".  Why should we be different, even
> macro> for now?
> 
> Please elaborate more ?  Do you mean we should implement default
> rtc_set_mmss() and take the rtc_lock in it ?  Or do you mean we should
> take rtc_lock in each board-dependent rtc_set_time/rtc_set_time ?  

 I'm not sure all chips actually require it.  Certainly the null function 
does not, so that spinlock would incur an unnecessary overhead.  Therefore 
yes, it should be board- or chip-dependent.

> macro> Also the call is named rtc_set_mmss() for an unknown reason
> macro> while all the others have set_rtc_mmss().
> 
> IIRC, you are (one of) the godfather of the function, aren't you?  :-)

 Hmm, I must have got influenced by rtc_set_time()...  Perhaps it wasn't 
that bad after all and it's all the others that should be fixed instead. 
;-)

  Maciej

From joey@infodrom.org Mon Sep  5 22:30:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Sep 2005 22:30:54 +0100 (BST)
Received: from luonnotar.infodrom.org ([IPv6:::ffff:195.124.48.78]:42251 "EHLO
	luonnotar.infodrom.org") by linux-mips.org with ESMTP
	id <S8225210AbVIEVah>; Mon, 5 Sep 2005 22:30:37 +0100
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
	id AD1F5366B79; Mon,  5 Sep 2005 23:37:27 +0200 (CEST)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
	from infodrom.org by finlandia.Infodrom.North.DE
	via smail from stdin
	id <m1ECOca-000ofLC@finlandia.Infodrom.North.DE>
	for linux-mips@linux-mips.org; Mon, 5 Sep 2005 23:35:20 +0200 (CEST) 
Date:	Mon, 5 Sep 2005 23:35:20 +0200
From:	Martin Schulze <joey@infodrom.org>
To:	Linux for m68k <linux-m68k@lists.linux-m68k.org>,
	Linux for MIPS <linux-mips@linux-mips.org>,
	Linux for PA-RISC <parisc-linux@lists.parisc-linux.org>,
	Linux for Powerpc <linuxppc-dev@lists.linuxppc.org>
Subject: Invitation to the Oldenburg Linux Developers Meeting
Message-ID: <20050905213519.GR27161@finlandia.infodrom.north.de>
Reply-To: Martin Schulze <joey@infodrom.org>
Mail-Followup-To: Martin Schulze <joey@infodrom.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Return-Path: <joey@infodrom.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8878
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: joey@infodrom.org
Precedence: bulk
X-list: linux-mips
Content-Length: 3285
Lines: 82

Dear developers,

there will be another Linux developers meeting taking place in
Oldenburg at the last weekend in September this year.  Like last year,
we will be able to start on Wednesday and work until Sunday.  So
diligent people can work up to four days in Oldenburg.


Executive summary:

URL:   http://meeting.ffis.de/Oldenburg2005/
What:  Oldenburg Linux Developers Meeting #A
Who:   Every developer interested in Linux on non-i386 platforms
       Every developer interested in developing the debian-installer
       Every developer interested in Debian-Java
When:  September, 21st to 25th (Wednesday noon to Sunday afternoon)
Where: University of Oldenburg, science building in Oldenburg Wechloy
Orga:  ffis e.V., Martin 'Joey' Schulze
Bonus: Regular rooms again, at least partially


The goal of this developers meeting is to provide developers a means
to work in common on the non-i386 Linux ports and related topics and
to further the exchange of ideas and discussion about these ports.
However, Debian developers and Debian Java people have asked whether
they can piggy-back a meeting at the same location as well.

We will have dedicated working and sleeping rooms in the university.
We are allowed to use the shower facility of the sports department
nearby where we can sleep as well this year.

We will have dinner together in a restaurant in the evening.  I'll put
a plan will be on the web soon.  If you prefer to stay at the
university and not go out having a dinner, please let me know in time
as this affects restaurant space requirements.

We will have a never-ending breakfast in one of the working rooms.
I'll get rolls each morning and try to ensure that there will be
enough butter, cheese, sausages, jam, Nutella and stuff.  I will also
take care of non-alcoholic fluids.

Beside machines, equipment and documentation you'll need to take with
you a sleeping bag, maybe a camping mat or cot, towels, shower stuff,
personal toilett accessories, maybe medicine, clothes.  A mug, plate
and cutlery are optional but helpful.  Don't forget enough power
chords, extenders and network cables.

You'll find routing information on the website mentioned above.

If you would like to attend the meeting, please send back the
following form, so that I can calculate space, power and food.

----8<--------8<--------8<--------8<--------8<--------8<--------8<----
Name ................:

Date of arrival .....: ( ) Wednesday, Sep, 21st
                       ( ) Thursday, Sep, 22nd
                       ( ) Friday, Sep, 23rd 
                       ( ) Saturday, Sep, 24th

Date of departure ...: ( ) Friday, Sep. 23rd
                       ( ) Saturday, Sep. 24th
                       ( ) Sunday, Sep. 25th

___ usable seats in my car, once arrived (only if you come by car)
(four usable seets --> one driver, three guests)

Special requirements for food: ______________________
(Vegetarian should be covered with 10% of all, vegan people will need
special attention)
----8<--------8<--------8<--------8<--------8<--------8<--------8<----

If you have any further questions, please don't hesitate to ask me.

Kind regards,

	Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Please always Cc to me when replying to me on the lists.

From anemo@mba.ocn.ne.jp Tue Sep  6 16:47:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Sep 2005 16:47:45 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:19925 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225407AbVIFPrX>; Tue, 6 Sep 2005 16:47:23 +0100
Received: from localhost (p4135-ipad30funabasi.chiba.ocn.ne.jp [221.184.79.135])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id E53A285B0; Wed,  7 Sep 2005 00:54:08 +0900 (JST)
Date:	Wed, 07 Sep 2005 00:55:17 +0900 (JST)
Message-Id: <20050907.005517.25909840.anemo@mba.ocn.ne.jp>
To:	macro@linux-mips.org
Cc:	spodstavin@ru.mvista.com, linux-mips@linux-mips.org,
	ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.LNX.4.61L.0509051620020.29615@blysk.ds.pg.gda.pl>
References: <Pine.LNX.4.61L.0509051204140.29615@blysk.ds.pg.gda.pl>
	<20050905.224534.25910293.anemo@mba.ocn.ne.jp>
	<Pine.LNX.4.61L.0509051620020.29615@blysk.ds.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8879
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 20724
Lines: 732

>>>>> On Mon, 5 Sep 2005 16:25:32 +0100 (BST), "Maciej W. Rozycki" <macro@linux-mips.org> said:

macro>  I'm not sure all chips actually require it.  Certainly the
macro> null function does not, so that spinlock would incur an
macro> unnecessary overhead.  Therefore yes, it should be board- or
macro> chip-dependent.

OK, and I also found some rtc routines might take a few SECONDS,
therefore protecting whole these rtc routines entirely with spinlock
is really bad idea.

How about this (untested) one?

* Get rid of inconsistent declarations from include/asm-mips/rtc.h
* Get rid of mips_rtc_lock.
* Use rtc_lock (and disable irq) to protect HW access in each rtc routines.

diff -ur linux-mips/arch/mips/ddb5xxx/common/rtc_ds1386.c linux/arch/mips/ddb5xxx/common/rtc_ds1386.c
--- linux-mips/arch/mips/ddb5xxx/common/rtc_ds1386.c	2004-08-14 19:56:00.000000000 +0900
+++ linux/arch/mips/ddb5xxx/common/rtc_ds1386.c	2005-09-06 19:57:17.000000000 +0900
@@ -41,7 +41,9 @@
 	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;
@@ -70,6 +72,7 @@
 		/* 24 hour format */
 		hour = BCD2BIN(temp & 0x3f);
 	}
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, month, day, hour, minute, second);
 }
@@ -81,7 +84,9 @@
 	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 @@
 	if (second != READ_RTC(0x1)) {
 		WRITE_RTC(0x1, second);
 	}
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/dec/time.c linux/arch/mips/dec/time.c
--- linux-mips/arch/mips/dec/time.c	2004-08-14 19:55:59.000000000 +0900
+++ linux/arch/mips/dec/time.c	2005-09-06 19:57:26.000000000 +0900
@@ -37,10 +37,25 @@
 #include <asm/dec/machtype.h>
 
 
+/*
+ * 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 @@
 	 */
 	/* 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);
@@ -78,6 +94,7 @@
 	 */
 	real_year = CMOS_READ(RTC_DEC_YEAR);
 	year += real_year - 72 + 2000;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
@@ -95,6 +112,8 @@
 	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 @@
 	 */
 	CMOS_WRITE(save_control, RTC_CONTROL);
 	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+	spin_unlock(&rtc_lock);
 
 	return retval;
 }
diff -ur linux-mips/arch/mips/ite-boards/generic/time.c linux/arch/mips/ite-boards/generic/time.c
--- linux-mips/arch/mips/ite-boards/generic/time.c	2005-08-30 11:01:59.000000000 +0900
+++ linux/arch/mips/ite-boards/generic/time.c	2005-09-06 19:57:42.000000000 +0900
@@ -149,15 +149,15 @@
 it8172_rtc_get_time(void)
 {
 	unsigned int year, mon, day, hour, min, sec;
-	unsigned int flags;
+	unsigned long flags;
 
 	/* avoid update-in-progress. */
 	for (;;) {
-		local_irq_save(flags);
+		spin_lock_irqsave(&rtc_lock, flags);
 		if (! (CMOS_READ(RTC_REG_A) & RTC_UIP))
 			break;
 		/* don't hold intr closed all the time */
-		local_irq_restore(flags);
+		spin_unlock_irqrestore(&rtc_lock, flags);
 	}
 
 	/* Read regs. */
@@ -170,7 +170,7 @@
 		hw_to_bin(*rtc_century_reg) * 100;
 
 	/* restore interrupts */
-	local_irq_restore(flags);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
@@ -179,18 +179,18 @@
 it8172_rtc_set_time(unsigned long t)
 {
 	struct rtc_time tm;
-	unsigned int flags;
+	unsigned long flags;
 
 	/* convert */
 	to_tm(t, &tm);
 
 	/* avoid update-in-progress. */
 	for (;;) {
-		local_irq_save(flags);
+		spin_lock_irqsave(&rtc_lock, flags);
 		if (! (CMOS_READ(RTC_REG_A) & RTC_UIP))
 			break;
 		/* don't hold intr closed all the time */
-		local_irq_restore(flags);
+		spin_unlock_irqrestore(&rtc_lock, flags);
 	}
 
 	*rtc_century_reg = bin_to_hw(tm.tm_year/100);
@@ -202,7 +202,7 @@
 	CMOS_WRITE(bin_to_hw(tm.tm_year%100), RTC_YEAR);
 
 	/* restore interrupts */
-	local_irq_restore(flags);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/jmr3927/common/rtc_ds1742.c linux/arch/mips/jmr3927/common/rtc_ds1742.c
--- linux-mips/arch/mips/jmr3927/common/rtc_ds1742.c	2004-08-14 19:55:33.000000000 +0900
+++ linux/arch/mips/jmr3927/common/rtc_ds1742.c	2005-09-06 19:58:03.000000000 +0900
@@ -57,7 +57,9 @@
 {
 	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 @@
 	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 @@
 	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_CENTURY and RTC_CONTROL share same address... */
 	CMOS_WRITE(cmos_century, RTC_CONTROL);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/lasat/ds1603.c linux/arch/mips/lasat/ds1603.c
--- linux-mips/arch/mips/lasat/ds1603.c	2005-08-30 11:02:01.000000000 +0900
+++ linux/arch/mips/lasat/ds1603.c	2005-09-06 19:58:25.000000000 +0900
@@ -8,6 +8,7 @@
 #include <asm/lasat/lasat.h>
 #include <linux/delay.h>
 #include <asm/lasat/ds1603.h>
+#include <asm/time.h>
 
 #include "ds1603.h"
 
@@ -138,19 +139,27 @@
 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 -ur linux-mips/arch/mips/momentum/jaguar_atx/setup.c linux/arch/mips/momentum/jaguar_atx/setup.c
--- linux-mips/arch/mips/momentum/jaguar_atx/setup.c	2005-08-30 11:02:03.000000000 +0900
+++ linux/arch/mips/momentum/jaguar_atx/setup.c	2005-09-06 19:58:40.000000000 +0900
@@ -149,7 +149,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/momentum/ocelot_3/setup.c linux/arch/mips/momentum/ocelot_3/setup.c
--- linux-mips/arch/mips/momentum/ocelot_3/setup.c	2005-08-30 11:02:03.000000000 +0900
+++ linux/arch/mips/momentum/ocelot_3/setup.c	2005-09-06 19:58:52.000000000 +0900
@@ -135,7 +135,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/momentum/ocelot_c/setup.c linux/arch/mips/momentum/ocelot_c/setup.c
--- linux-mips/arch/mips/momentum/ocelot_c/setup.c	2005-08-30 11:02:03.000000000 +0900
+++ linux/arch/mips/momentum/ocelot_c/setup.c	2005-09-06 19:58:59.000000000 +0900
@@ -140,7 +140,9 @@
 	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 @@
 
 	/* 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 @@
 	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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/pmc-sierra/yosemite/setup.c linux/arch/mips/pmc-sierra/yosemite/setup.c
--- linux-mips/arch/mips/pmc-sierra/yosemite/setup.c	2005-06-24 10:01:20.000000000 +0900
+++ linux/arch/mips/pmc-sierra/yosemite/setup.c	2005-09-06 19:59:19.000000000 +0900
@@ -73,7 +73,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	m48t37_base->control = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/sgi-ip22/ip22-time.c linux/arch/mips/sgi-ip22/ip22-time.c
--- linux-mips/arch/mips/sgi-ip22/ip22-time.c	2005-08-30 11:02:04.000000000 +0900
+++ linux/arch/mips/sgi-ip22/ip22-time.c	2005-09-06 19:59:43.000000000 +0900
@@ -35,7 +35,9 @@
 {
 	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 @@
 	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 @@
 {
 	struct rtc_time tm;
 	unsigned int save_control;
+	unsigned long flags;
 
 	to_tm(tim, &tm);
 
@@ -68,6 +72,7 @@
 	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 @@
 	hpc3c0->rtcregs[RTC_HUNDREDTH_SECOND] = 0;
 
 	hpc3c0->rtcregs[RTC_CMD] = save_control;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/sibyte/swarm/rtc_m41t81.c linux/arch/mips/sibyte/swarm/rtc_m41t81.c
--- linux-mips/arch/mips/sibyte/swarm/rtc_m41t81.c	2005-08-30 11:02:04.000000000 +0900
+++ linux/arch/mips/sibyte/swarm/rtc_m41t81.c	2005-09-06 20:00:03.000000000 +0900
@@ -144,6 +144,7 @@
 int m41t81_set_time(unsigned long t)
 {
 	struct rtc_time tm;
+	unsigned long flags;
 
 	to_tm(t, &tm);
 
@@ -153,6 +154,7 @@
 	 * 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 @@
 	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,14 +190,17 @@
 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);
@@ -207,6 +213,7 @@
 	day = BCD2BIN(day);
 	mon = BCD2BIN(mon);
 	year = BCD2BIN(year);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	year += 2000;
 
diff -ur linux-mips/arch/mips/sibyte/swarm/rtc_xicor1241.c linux/arch/mips/sibyte/swarm/rtc_xicor1241.c
--- linux-mips/arch/mips/sibyte/swarm/rtc_xicor1241.c	2005-03-04 10:19:33.000000000 +0900
+++ linux/arch/mips/sibyte/swarm/rtc_xicor1241.c	2005-09-06 20:00:28.000000000 +0900
@@ -113,9 +113,11 @@
 {
 	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 @@
 	xicor_write(X1241REG_HR, tmp);
 
 	xicor_write(X1241REG_SR, 0);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
@@ -167,7 +170,9 @@
 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 @@
 	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 -ur linux-mips/arch/mips/tx4938/common/rtc_rx5c348.c linux/arch/mips/tx4938/common/rtc_rx5c348.c
--- linux-mips/arch/mips/tx4938/common/rtc_rx5c348.c	2005-08-30 11:02:04.000000000 +0900
+++ linux/arch/mips/tx4938/common/rtc_rx5c348.c	2005-09-06 19:56:27.000000000 +0900
@@ -67,14 +67,20 @@
 {
 	unsigned char *inbufs[1], *outbufs[1];
 	unsigned int incounts[2], outcounts[2];
+	int ret;
+	unsigned long flags;
+
 	inbufs[0] = inbuf;
 	incounts[0] = count;
 	incounts[1] = 0;
 	outbufs[0] = outbuf;
 	outcounts[0] = count;
 	outcounts[1] = 0;
-	return txx9_spi_io(srtc_chipid, &srtc_dev_desc,
-			   inbufs, incounts, outbufs, outcounts, 0);
+	spin_lock_irqsave(&rtc_lock, flags);
+	ret = txx9_spi_io(srtc_chipid, &srtc_dev_desc,
+			  inbufs, incounts, outbufs, outcounts, 0);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+	return ret;
 }
 
 /*
diff -ur linux-mips/include/asm-mips/mc146818-time.h linux/include/asm-mips/mc146818-time.h
--- linux-mips/include/asm-mips/mc146818-time.h	2004-08-14 19:55:59.000000000 +0900
+++ linux/include/asm-mips/mc146818-time.h	2005-09-06 18:38:47.000000000 +0900
@@ -33,7 +33,9 @@
 	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 @@
 	 */
 	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 @@
 
 	/* 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);
@@ -121,6 +140,7 @@
 		BCD_TO_BIN(year);
 	}
 	year = mc146818_decode_year(year);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
diff -ur linux-mips/include/asm-mips/rtc.h linux/include/asm-mips/rtc.h
--- linux-mips/include/asm-mips/rtc.h	2005-09-05 10:17:18.000000000 +0900
+++ linux/include/asm-mips/rtc.h	2005-09-06 16:17:02.000000000 +0900
@@ -14,7 +14,6 @@
 
 #ifdef __KERNEL__
 
-#include <linux/spinlock.h>
 #include <linux/rtc.h>
 #include <asm/time.h>
 
@@ -29,23 +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 */
 
-unsigned int get_rtc_time(struct rtc_time *time);
-int set_rtc_time(struct rtc_time *time);
-unsigned int get_rtc_ss(void);
-int get_rtc_pll(struct rtc_pll_info *pll);
-int set_rtc_pll(struct rtc_pll_info *pll);
-
-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;
 }
@@ -55,12 +44,10 @@
 	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;
 }
diff -ur linux-mips/include/asm-mips/time.h linux/include/asm-mips/time.h
--- linux-mips/include/asm-mips/time.h	2004-08-14 19:54:51.000000000 +0900
+++ linux/include/asm-mips/time.h	2005-09-06 19:38:52.000000000 +0900
@@ -20,6 +20,9 @@
 #include <linux/linkage.h>
 #include <linux/ptrace.h>
 #include <linux/rtc.h>
+#include <linux/spinlock.h>
+
+extern spinlock_t rtc_lock;
 
 /*
  * RTC ops.  By default, they point to no-RTC functions.


From anemo@mba.ocn.ne.jp Tue Sep  6 17:34:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Sep 2005 17:34:57 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:59372 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225548AbVIFQee>; Tue, 6 Sep 2005 17:34:34 +0100
Received: from localhost (p4135-ipad30funabasi.chiba.ocn.ne.jp [221.184.79.135])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 18EB68463; Wed,  7 Sep 2005 01:41:26 +0900 (JST)
Date:	Wed, 07 Sep 2005 01:42:34 +0900 (JST)
Message-Id: <20050907.014234.108739386.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: unkillable process due to setup_frame() failure
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8880
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3743
Lines: 128

For a long time, this test program is unkillable (by SIGKILL) on
Linux/MIPS.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void sighandler(int sig)
{
	printf("SIGNAL %d!\n", sig);
	exit(2);
}
void setup_signal(int sig)
{
	struct sigaction act;
	memset(&act, 0, sizeof(act));
	act.sa_handler = sighandler;
	act.sa_flags = SA_NOMASK | SA_RESTART;
	sigaction(sig, &act, 0);
}

int main(int argc, char **argv)
{
	setup_signal(SIGTRAP);

	__asm__ __volatile__("move $29,$0");
	__asm__ __volatile__("break");
	printf("done!\n");
	return 0;
}

If we run this program,

1.  The "break" instruction raises a exception.
2.  The exception handler queues SIGTRAP(5).
3.  dequeue_signal() dequeue a signal with LOWEST number (i.e. SIGTRAP).
4.  setup_frame() fails due to bad stack pointer and queues SIGSEGV(11).
5.  returns to user process (pc unchanged).
6.  goto 1. (forever)

So, the process can not be kill by SIGKILL.  In 2.6.12, 'sigkill
priority fix' was applied to __dequeue_signal(), but it does not help
while the SIGTRAP is queued to tsk->pending but SIGKILL (by kill
command) is queued to tsk->signal->shared_pending.

I have two proposal fix:

1. Now do_signal() returns 0 if setup_frame() failed.  Therefore if
   do_signal returned 0 (and there is still pending signal), calling
   do_signal again will handle the SIGSIGV.  Like this:

--- linux-mips/arch/mips/kernel/signal.c	2005-08-30 11:02:00.000000000 +0900
+++ linux/arch/mips/kernel/signal.c	2005-09-06 15:07:45.000000000 +0900
@@ -481,6 +481,10 @@
 {
 	/* deal with pending signal delivery */
 	if (thread_info_flags & _TIF_SIGPENDING) {
-		current->thread.abi->do_signal(oldset, regs);
+		if (unlikely(!current->thread.abi->do_signal(oldset, regs)) &&
+		    unlikely(signal_pending(current))) {
+			/* SIGSEGV mighe be sent in setup_frame */
+			current->thread.abi->do_signal(oldset, regs);
+		}
 	}
 }



2. Make 'sigkill priority fix' can handle this case.  First search
   SIGKILL in tsk->pending and tsk->signal->shared_pending, then
   search another signals.  Like this:

--- linux-mips/kernel/signal.c	2005-08-29 08:41:01.000000000 +0900
+++ linux/kernel/signal.c	2005-09-07 01:33:52.338420760 +0900
@@ -520,19 +520,14 @@
 }
 
 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
-			siginfo_t *info)
+			siginfo_t *info, int sig)
 {
-	int sig = 0;
-
-	/* SIGKILL must have priority, otherwise it is quite easy
-	 * to create an unkillable process, sending sig < SIGKILL
-	 * to self */
-	if (unlikely(sigismember(&pending->signal, SIGKILL))) {
-		if (!sigismember(mask, SIGKILL))
-			sig = SIGKILL;
-	}
-
-	if (likely(!sig))
+	if (sig) {
+		/* check signal with priority first */
+		if (likely(!sigismember(&pending->signal, sig)) ||
+		    sigismember(mask, sig))
+			sig = 0;
+	} else
 		sig = next_signal(pending, mask);
 	if (sig) {
 		if (current->notifier) {
@@ -561,10 +556,18 @@
  */
 int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
 {
-	int signr = __dequeue_signal(&tsk->pending, mask, info);
+	/* SIGKILL must have priority, otherwise it is quite easy
+	 * to create an unkillable process, sending sig < SIGKILL
+	 * to self */
+	int signr = __dequeue_signal(&tsk->pending, mask, info, SIGKILL);
+	if (likely(!signr))
+		signr = __dequeue_signal(&tsk->signal->shared_pending,
+					 mask, info, SIGKILL);
+	if (likely(!signr))
+		signr = __dequeue_signal(&tsk->pending, mask, info, 0);
 	if (!signr)
 		signr = __dequeue_signal(&tsk->signal->shared_pending,
-					 mask, info);
+					 mask, info, 0);
  	if (signr && unlikely(sig_kernel_stop(signr))) {
  		/*
  		 * Set a marker that we have dequeued a stop signal.  Our


Which are preferred?  Or is there other solutions?

---
Atsushi Nemoto

From clem.taylor@gmail.com Tue Sep  6 18:46:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Sep 2005 18:46:42 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.201]:43648 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8225744AbVIFRqZ> convert rfc822-to-8bit;
	Tue, 6 Sep 2005 18:46:25 +0100
Received: by wproxy.gmail.com with SMTP id i32so883580wra
        for <linux-mips@linux-mips.org>; Tue, 06 Sep 2005 10:53:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=h6cNjHGvnz+4NuoPAdR03n//9YhH5zW4ThwjMHaTKoDcJuRgF7BU0FqeKaCjmZIcBeb9vepE+IA1Hbpu/yYVJde00L/QMjiEc/ZM7Bz7vulPXvBQ9trUM5Symr2C0Scflmoe4/4Dr9+vvhWIULwuoFA4PfO5qlvF7y06CW+t5Yw=
Received: by 10.54.36.9 with SMTP id j9mr4492932wrj;
        Tue, 06 Sep 2005 10:53:13 -0700 (PDT)
Received: by 10.54.41.29 with HTTP; Tue, 6 Sep 2005 10:53:13 -0700 (PDT)
Message-ID: <ecb4efd1050906105332061e5a@mail.gmail.com>
Date:	Tue, 6 Sep 2005 13:53:13 -0400
From:	Clem Taylor <clem.taylor@gmail.com>
Reply-To: clem.taylor@gmail.com
To:	linux-mips <linux-mips@linux-mips.org>
Subject: Problems with CONFIG_CC_OPTIMIZE_FOR_SIZE?
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <clem.taylor@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8881
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clem.taylor@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 521
Lines: 12

Hi,

I recently configured my MIPS (Au1550) kernel to use
CONFIG_CC_OPTIMIZE_FOR_SIZE to match the way the rest of the system is
built and discovered that with this option enabled /sbin/reboot
stopped working, the system just hangs after printing 'Resetting
Integrated Peripherals'. I'm using gcc 3.4.4. I haven't noticed any
other problems (but I've only done minimal testing) and I was
wondering if anyone else is using CONFIG_CC_OPTIMIZE_FOR_SIZE?

                            Thanks,
                            Clem

From ralf@linux-mips.org Tue Sep  6 19:34:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Sep 2005 19:35:00 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:40727 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225744AbVIFSef>; Tue, 6 Sep 2005 19:34:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j86IfNUi001612;
	Tue, 6 Sep 2005 18:41:24 GMT
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j86IfLll001611;
	Tue, 6 Sep 2005 19:41:21 +0100
Date:	Tue, 6 Sep 2005 19:41:19 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
Message-ID: <20050906184118.GC3102@linux-mips.org>
References: <20050907.014234.108739386.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050907.014234.108739386.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8882
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 828
Lines: 19

On Wed, Sep 07, 2005 at 01:42:34AM +0900, Atsushi Nemoto wrote:

> 1.  The "break" instruction raises a exception.
> 2.  The exception handler queues SIGTRAP(5).
> 3.  dequeue_signal() dequeue a signal with LOWEST number (i.e. SIGTRAP).
> 4.  setup_frame() fails due to bad stack pointer and queues SIGSEGV(11).
> 5.  returns to user process (pc unchanged).
> 6.  goto 1. (forever)
> 
> So, the process can not be kill by SIGKILL.  In 2.6.12, 'sigkill
> priority fix' was applied to __dequeue_signal(), but it does not help
> while the SIGTRAP is queued to tsk->pending but SIGKILL (by kill
> command) is queued to tsk->signal->shared_pending.

The behaviour of not advancing the EPC beyond the faulting instruction is
part of the problem - but I believe that was the usual behaviour for
MIPS UNIXoid operating systems.

  Ralf

From redhatter@gentoo.org Wed Sep  7 00:58:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 00:59:53 +0100 (BST)
Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:36019
	"EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP
	id <S8225756AbVIFX6n>; Wed, 7 Sep 2005 00:58:43 +0100
Received: (qmail 29360 invoked by uid 210); 7 Sep 2005 10:05:28 +1000
Received: from 10.0.0.251 by www (envelope-from <redhatter@gentoo.org>, uid 201) with qmail-scanner-1.25st 
 (spamassassin: 3.0.2. perlscan: 1.25st.  
 Clear:RC:1(10.0.0.251):. 
 Processed in 0.124962 secs); 07 Sep 2005 00:05:28 -0000
Received: from beast.redhatters.home (HELO ?10.0.0.251?) (10.0.0.251)
  by 192.168.5.1 with SMTP; 7 Sep 2005 10:05:27 +1000
Message-ID: <431E2ECF.1050501@gentoo.org>
Date:	Wed, 07 Sep 2005 10:05:35 +1000
From:	Stuart Longland <redhatter@gentoo.org>
Organization: Gentoo Foundation
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Indy R4600 on Linux 2.6 -- possible cache issue?
X-Enigmail-Version: 0.91.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="------------enigF5FF44C2CBFAA49ADC82EF21"
Return-Path: <redhatter@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8883
X-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
Content-Length: 11734
Lines: 203

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF5FF44C2CBFAA49ADC82EF21
Content-Type: multipart/mixed;
 boundary="------------010900070008010907040109"

This is a multi-part message in MIME format.
--------------010900070008010907040109
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi All,

I've been tinkering with my Indy, trying to coax the contankerous
machine into booting Linux 2.6, until last night, without success.

For the record, the Indy's specs are as follows:
CPU:	R4600 SC rev2.0 @ 133MHz
RAM:	256MB
HDD:	9.0GB IBM SCSI
Video:	8-bit Newport (XL)

It successfully boots Linux 2.4 without incident... even in 64-bit mode.
---------------------------------8<-------------------------------------
> Linux indy 2.4.29-mipscvs-20050130 #2 Tue Feb 8 19:44:48 EST 2005 mips64 R4600 V2.0  FPU V2.0 SGI Indy GNU/Linux
>   09:36:06 up  8:02,  0 users,  load average: 0.02, 0.01, 0.00
--------------------------------->8-------------------------------------

The tests below have been conducted using the stock ip22_defconfig with
debugging options enabled and CPU set to R4x00.

Previously, it would either not boot at all, or it would just get past
starting userland before hard locking (as in, no SysRq joy, and no
response from pressing the power button).

My current kernel, made from a CVS HEAD snapshot last Sunday (4th
September) with cache disabled is the first one I've made which boots
consistently, although it's _very_ slow.

I'm wondering if we could be hitting a caching issue with the R4600 CPU?
 I also suspect the wd33c93 SCSI driver has a role to play in the
instability, as I'm getting a lot of warnings from it, they all look
something like the following

---------------------------------8<-------------------------------------
> [timestamp] drivers/scsi/wd33c93.c:77? spin_is_locked on uninitialised spinlock 893ce340.
--------------------------------->8-------------------------------------

The exact line number scrolls too quickly to read. (I'm not using serial
console presently -- I might try that later though)

As I say, the system boots, and in fact, I had the machine successfully
running e2fsck on its root partition (8GB) last night with this kernel.
 After 2 hours or so, it managed to get 75% though the filesystem check
-- I don't know beyond that, as it was approaching 1:00AM and I needed
sleep. ;-)  It's running extremely slow though, so I'd like to discover
what's causing these crashes.

The crashes happen on most boots with cache enabled.  Occasionally, I'll
get lucky, and the machine will boot on its own, but it's like 1 in
every 5 boots or so.

I'll see if I can get a dump out of this box, but as I say, it gets
through a file system check and activating swap, that's further than
I've ever got this machine running with cache enabled.
-- 
 ____                   _             Stuart Longland (a.k.a Redhatter)
/  _ \   ___    ___  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \                        Developer
 \    //  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \____/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter

--------------010900070008010907040109
Content-Type: application/gzip;
 name="debug.config.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="debug.config.gz"

H4sICPUqHkMCA2RlYnVnLmNvbmZpZwCMPFtz2zaz7/0VnPThS2aaRjfTcmf8AJKgBIs3A6As
54Wj2KytE1nSSHJa//uzIEURIAGqD3HM3QWwXCz2hqV//+13C70ft2/L4+ppuV5/WC/5Jt8v
j/mz9bb8mVtP283fq5e/rOft5n9HK39eHWFEsNq8/2v9zPebfG39yveH1XbzlzX40/6zP/z6
ttodnn4dvg56vaveTW8E9Pw9t1i+syzbGvT/6g3/6t9YAv3b77+5ceSTSRaShN1+/AaA3y13
+5zD4sf3/er4Ya3zX7DIdneENQ71ALxIMCUhjjgKYOAJ6gYYRZkbhwkJcA12aDzDURZHGQuT
GkwiwjMczTNEJ1lAQsJvh4OSh0khhbV1yI/vu3rVIHZRMMeUkTi6/fR1tRsMvu5HPz9VePaA
pPnZI5uTxAUAvFQJSmJGFll4n+IUW6uDtdkexRo1gcO8LKGxixnLkOtymaie1uWBPCtKPcK1
001jngTpRDPLLHbusMuzFM9BiJJQZuUvbUjBVw3GoYM9D3s1ZIaCgD2GTGatgmXwv5bDMwFe
cIqyBDGm4TahJOIzaUdTiUEHMZz5aSApgp9yvJB4TeJAkZjrZnHCYcu/w8iYZgx+0Yl6GuJQ
Ui8XXoNMIpg+cjnoALvttXABcnCgRcRxooPfpWEBPzPHSfRYLq1hqXhZFoLUYEihq8F2+bz8
sYYzs31+h/8O77vddn+UDlfspQFm9XuUgCyNghh5slhOCJCIW6E1LMQOiwPMsSBPEA2ViU+n
o70ao+4JJ3RB0hrAV0c/XD69rjbwCvk6fxInvjQItY3IQr7oa/WowDoxS2KaMjNF4vR7vV4n
vn8Bf3UJf9WNH3SN9y7w513gz7vAn3eBP+8CfyGhaILNeDd2UKC3RSFyp5mHXcaRODvmOfDc
HgEXXQQ3dqcUyJx2IDke968HZh7v0PfvWmyAGOLmiREHgg7RgWCQGc2wetikQwluzo2BrUmK
KKyy6CQD3xHE/D+QZMP/QuT+F6KJ+bUWC2bUyCRajEEbs/kgcUknxZ2jF6znOVe965ERN7q2
O3DXZh2Y01F/oRd0ErrZY8wwxAv6g3CPw1TnTCYkI8lgIBvcE0zPSIkc6jWVEecRTDBEHDTs
JADvHjPURUKncYS7CFxYAwddFAm/yEhAOAcvlNLOleiUXOClg9uIZDQE85WZ1AkkMSUOyu5C
OrwxSL2ioQ5fjP4b0XCs2W76ACqSTXAEcaqbsYSAO3WlEKbCQERJHIrg1TwcoMeaYIrmAuZm
6jhEpSDMC1EWxXASp5gqYVyBwNgTogCNTjJhdaWQ2E3SzBGRUeQRFCmhEWDKvToh9SFoxtIE
fC1n6jRVzEjvxURSLAyRcUZikANysfIyw4EUycVgTHDgy7DCigR9kJM7BXWeEp/fXknjweVE
Ih5RJhWxaghyPecUSaoPKsTbihWGg4zqAwuZYtBJYY8uzSEozHPQocn1CyxfDG8MFkmgOwxW
MfdoqM6t4Ba9XlMFhF53zXfVxSu9Gg073tPuGhvhOfKQefC4c2ERPXWgw+tu9E0Xmjn9S2dh
OHAgp5xhGuFASQRrEnukIynm755FIWnMUqj0rEzIjx+7vA7+i7nkzS1G6lIsiOuKPCgbzRwl
Zz0jxjNH7xHPFH37Iok9UknORx9RL2PFKZfsCPjL8sUrRDMd0K5WSieZgtyR51HjjiJvjiIX
e4aDMUVgeQLmqntQQj3mem04e4zctomfwquBRWRtjLCTYKoc1XpNMz9AHPI/sKvIkU0bw4FI
2gEV00eRWckKUg0KUZQiJd31CIPfOJnUaL0HhXQOvJaWSF1EXRV8kIezclyi6A7FOEwEPsLa
tL5Ez+MgjTiij5qx8rBCzZ33Q1UPsj6De/vDStzQJegPCxMGP4sf3P1Sn4HpQ7E5Ai0vIJ41
TIVhWp2oxIXQxxOriAW+ucv9M6z+RUqxa25L0iazIhKZbo+79fuLxc6jChT+N396PxaZ+98r
8WO7f1sepRqXQyI/LPyh5CFLWAgbevtWATlFcHTIJELBuYoW5cd/tvufq81LPWGEeRvdrq2B
i55hKZYon0EucnErjYhUYFn4chlAPGUpw7RmEZYGa/UoF9/kJUiShWnAiYuYYqwAXp3RjMYp
x1SzYUDkE0ds8VSZMYmSxlwAybypm+gnEVgRgehGUUQT7ZERL0YS0oWcUH28Kl66eCktFhbU
54NgYyDmiWcE6yplQq4ZmtaSLwCYJQ0ISUSZtAHkaST8yZskFO4mENpNdDD4dW7LsgK4iMYm
XXb1TOMQt1JGkvxlzVf74/tybbF8/yvfW25Rd37fL08BW734nAEvsgznDKJkR1vkLLEcObAa
Z7f9QbXenFnH/XJzEOfR2u23x+3Tdm2tt8tn68dyvdw8iYPRKqSV04G95rF4D0XZzojUMyDE
HmgRaFoLAhg7PL3mopC3by5MqbILAHlogwK3RdQGBY4e1prNmzYhrA3BXhMU3QOkfqPlbrde
PRVbab3m61371Xwuq6JQK+VJ1H/nyG2YD7ul53Zb0W2tptsaVZ+3gUDpkwCsjqzlZ2Bb7c7a
DOYVbPqxU5EjXxyECIw3pHdvDQQvqv+Kvsj04GfprGGmymGlSjGXG4wcUDWELUCEuk0Q15Ah
CAs81IQWtxmtGRMuQhfWhIeIQ3xT3rZoUSShKJpgPTJErh6RzDh/TIyj6MyAEU5HRNR6NKT5
egTFrki3tTjsRnoEhIyJHoOmDcWVRYWjCZ8a+OOBAeEmITPwPsVBgqkeV1YJtCijrpbo+CEy
TSpCcPPmUIyC0MCNyxMTM2Fo3ADBqXnLRZigVb/TSW8eA0Qn4BkpFrdlBmQQTwyY1IzSb1GE
uAZUlHLkqzZlphAxOIIQA2Ij85B+mNkHgyZCOz2SoRDrOGJRmIjLKOLqsBp7IsAakyLA3ADX
mxsATgLTq2pO7AmjOZYnjO5cnkXbVqMTyg0QY8R/NKENSngenTLQNtJamKIH0zbF2uMHcaLe
0gJCr9KAqIV4clm/bKPTsj7Ll+1fZB9ma82/bbL/docDsI1GXsJQ05A44aaVfKpGrxJqGpg4
0LkFu8PY2WZnY8uubW5PMZxT01g0bbgBu8sPSEicEnvUwrW33zZbLVt/tuyO02DXCluoURF1
/Ffdqax7ndfAc+Y5kIAz/X3SmSB27tyIm2mmoEGtkoOGhE2RtqJ3Jgi9K6XPgutvOBxKPMOl
6DxAUTbuDfr3+nsosEpY/yZB4A4MaaO+LItAwjMtZjG4MtxnJrpSnMgEPTLHVEnFMfxvYPUB
3tGYnYvZmDvFXiOGFkAwg7Psjvi+PpeVqUD/OKhR7Hvo0TSTqPJ3zOLcq/UIAZxyRwP05epK
BYUcJG5DqZz9VEDma5bi+D7QQB2/DZxoZ/WYegArOPyPwzaYRDCNHGEIxH0sVSHLygCIFfGY
qmA3YC1A091XYO6SyMOLNqLQiZEB3p7ef2iTpsOBbCNOoAxsim+suAgi4Ehf9T1NICRp0JWC
QzZPNHwD1JbZKQRYWOBOZpC2j6vCJnFAijsxuTBnHfPDsSzeKdNBnjPB+t6JKQohBiSx3mhQ
w52K0y6wevmv1VNuefuV6O2rypVFS9zq6QS24mbVEFIHCNYCMBJS5ZAW3WXgiGj4gCjOnJQE
iiHwHzLRZYSpwTxCgp15VBijFpth/rbdf1g8f3rdbNfbl48T4wfrc8i9L0rrENdUZpf75Xqd
r62iBqSr6EKcBCFAe6Co5S43z/DL8kMaWBan19unn9ZzyYg8mwP2ycPzzNfrZYV244ciuTH0
x1RkopeskyByutehSNtcVmOBixQSrL4td0sC3GcZi1MKCvvp3PboejQOhWq63lyyWwoYtt73
MWW3Y+kwKgQPxRVPu5wSW6yqiEnqRuLCqYCbj+Wy2gmKWBvmQeQVEFk9K4wL5rq+f+Eoi0Hf
MlxEWwUPAPsG/xLyLfTDbzQIdPpCvDbzzGXkpA3tcqJASlc78FS0WGb+uYhfDD+NK+71rM/P
q8PPP6zjcpf/YbneVxCgFFVV+8fkq6kpLWGKN6+gMWO8QxGYUvmqoRkcay82XKxVC+oqsmek
exYu277lsqDg/OZ/vvwJb2f93/vP/Mf23/OFi/X2vj6uduvcCtJIOV6F9IqwPQOUNqgDAtEq
AGaKKy2qBQaC4Qk4TP0G8nOpGB2P+9WP92N+ULdR9HeA5nDK1IgWML5bIkw8keJnNbZedL39
52vZ/Px8NsR1Y9CDdzOsFEhdjyFDl1mB1ZcsQyHWr6qeWp8pIl5h6IJ5qJrTtjX130UTuCXu
61rqXhv7lDUa/8oTjjG2+sObkfXZX+3zB/j3pWlXySBuT6w4TNMpA68JCgceVjIJXhqGUuLu
xJEHm18D8H2KAvJdzp14GlXbg4+v4qYdJNTvWdu91e/1wh+r4xdlTWE+xO08V++sib4xjGF8
Xx16efpez6qm1uAaSL79mW8sKq4uagdUYIRI1/nhYEE2Yn3ebDdfX5dv++XzavulGWC0Qohy
guXGWm2O+f7vZcOvPSC9p0oSvYNigeGuDJKxxBAGAF+nJh8TWvR3G0MwgRRHn1P4RRNIEOZF
oDc/Dh+HY/6mmHSBaZJzEOXudbv5kC5069dudqeVK2x270ejhpIoSc8Xs+kh36/FoVPELVNm
YZwyDDotX2nI8CxhKF3IdyUKlrkU4yhb3PZ7g1E3zePttS3565LoLn4EEn2UWRBw1o3H80t4
7bVKIcNWbKqMnOHHoo9E6i4/QcDAzhwl8jxjWBrNDNHSmSaYXSRZ8IskEX7gcaS9tD1LX+6b
h0fYy0G9zyWIYUpQIDuaEj5ni8UCoQ7JwtZBuufOujYvTt1puf0dVKL/oLVD0+X++Z/lPrfI
t7iIqmWXhUX2/KE8ZmTcGw2aQPhZVN4a4IA4QhQNaFl8OjM3QSHWxuzuK0T7T6K0WVvGqkIj
LTXn7W7C6YMEq61VsQeiyFTmPZrWDwbp0lL23s3B44HaiV+6MzDOBeJQDm9kJ+oMRXvUd6JU
8k4oN6ZSHU90a9yMs4Q/Sl4wwBPkPhqBpwxgcGVXReKQKMYRniHpjDydTX1YHp9en7cvluiZ
kaT9IJJlL57IsqxgIM0H9Bin3Dxb6/jXMo19fp5Je8S8R6+Q03kI5a6hTdtj/cFYyfQh6W7S
11kqN9Td6PDGHrVDpTJ4B09u/b3e7nYfRTRfeYdSXWqBgYafEmDJDKBFCcdzVu8PT8Km3ycD
V+NuBq7SQTFwISoHBVZt8nk8Wr9s96vj69tBmSJDwSR2lBr+CZi4vg6I2kAh6/MVBCx1NiCi
xUvHdyY6uJRpTkk6mIfJtMEL46nTIHbRaQbl7RmG462pL6wOT/kafHG+BXYEf+7raqeLa8sJ
mFCb4dDQyy+RGL5XqEgwFs3LnSQg4vHVhWngZW+uhjeX57npd9KA1o+v7O61QCHt8bW+yCwk
XNZxhEm6QCK04gKJY/i8S1pnqoaYZVFrCVt5+N/B6n/9B6Jh68e7Gsb2ze4s3G5WRzgDSktQ
XXZ7CDU5jVCe5mkssqy3/Hm11Hgh4uE4K4O6gni+es63lg/pRfG1bTVHCUbPy92xYQDLGdyE
6AOAEs0QuhqM7Msker2BJAjTbNgb2hrDWQ6fkyiWD1gJjecuCrX7QkUWon2hIhMB1cIMAvf2
fq5eVkfwj6VAnP12+fy0LEqmVRlQnsubO60ZJvvl7nX1dNBmqm1yd7s5bNdgoFeHnSj8lYZa
N3g+QZkmX5H8CwSChdVqBRtFYtoG+5C8ZON/+3aVJQTbl+3p2+xWaxFEA7HsXsUz2McoXUCc
GOmPl0QD3PftS0RukPLBYKR5vYJIvOOJ5FzK2r5vnlWHnUbtoClljk6kAC4bo0Uf79TVx9kK
UTxVvwE6zz5ZPr9AAs30i0yQN8HtACQM3W/MK4IZHXuA1uQrf682K0ekco2KBYskFS1DAtH/
W6afyjfufCCKgdJpOoGyhagXaYVwpiC6BjDADsv6ogooJ2yDy+/VkRu0UQy7KSVc6sm7UxMs
eDQ2ZsL40Gm19FNMIHoFnK838XctVD2dzGkh0wVQtmKIRTFDHRWIZ7w45Rv1fakv3J5mHYG4
T2OO5F5nRRTKHGeedF3mBELyxu6C2ze9IVhVLppNzutWbNRfHYq+8LnuPrvESGlkMbb8GwKV
3WlOj1IeN2RVgkYlrNT+ov78zZt7hQa3FJiw+Ma2e8osd3FA5M7v70AkK2T5rAxJPb/1HNWd
7l7MvvmIf4u4ngtfNB5Jw0MGIxTIvEkinj3sozQQNtrD4uuV29HwWocnsYieGbzTp9VhO4Z4
6mv/k1SA4q0tLW+RDvn787bo/G9xXN8CyIBZkdLJHxXJJBA6JJxpjnKN0KkpDxPDYZumYAgD
p/hyR/d5o7gKOn+3r4TK6jvV/Qme+WQj34ybdqKSIDWiHWwe6phOGq60r77QKN5VHzItOphL
zLj7aDEyY8UfDtEzl7aYKyHZA218jazUxgv/wppqFjXOmXieD6V7+eL5ZFNrhRZQfTogUGWn
oVpCrtGespoHVkl1LiVw2AJomPAaXMgYpTlffD4rrVs8wljZowkH0JQErFh9bqciyutZ6SCm
EU2ktojyOZvIrRcAgNMnYNmMOleK0a9RLJmFQ13IGDrKRolnMICVCZJYOSEoDmOObz897cBo
1de0pKHXRBgFjrheCwu0OdAo0HJ3l14l3ESvyWBWUfOclaAsDrwMJcRgKPTWdLk/roqGM/6x
y5VvmSgnvPijI6dvUpSGLjCpUU2jXTFm/gUKFJIJukTDESUXaETHmZZCcVxnCuVmFpTeI2xW
/PEZwx9jEPEGS51uHiDvAEZh38f2BW5FSbHo6eheN/DCzpcSqYL2lUCxKXB8gd300vZh3yD2
0kBC7vQrt4Ll5uV9+ZJLWUGlv4FsFqQzJzt7CV1FCxkcPHXgGXNtxlxfGTDjq54RMzBizLOZ
OBjbxnXsvhFj5MAeGjEjI8bItW0bMTcGzM3QNObGKNGboel9bkamdcbXjfeBKFZoRzY2DOgP
jOsDqiFqxFxC9PP39eCBHjzUgw28X+nBth58rQffGPg2sNI38NJvMDOLyTijGliqwlLuj6t0
JdlvITQ1lPEgxPZJoGsBOX1W/7p8Ur+mLf8mWSa6UuVoW1Qgm5/uh2gi/gbII6P3clzy/22c
3W6CMBTHX2WvgJElu4S2aCO0pC0h824zZvFicyHuwrcfp61Ses4V4ae0p1Ug5+sPwcwmSloU
26UqZC+4fy3nw9r5MYsYEhZZ8/kiIXpkYFB/y7FUjc5Z6mQwo61F8nqsC3VVS0FYNMFBp9pg
wXlKE687TlUdm0HBVoZrM/mPQflYwVMnzJ5PQR0Q9S4fRJrMgrNoTHChwqdJ/Dp4RDjYN91/
b9evECHEszDz3jud7guc+5pxBBUI031nsONbgpWIQYU6BTflK4XLYoPw2FPU7UzxhjFPGzYi
q1s9NjLt+3yMMWqSQwZ31ZwVeUUMDg3fJUnxAp2o8JiG4Z087KtjxfF31VBLS6wZJAwE+uE6
OTv2ooUjNhB0axhhoXWPp80zfXDy/6U8GdBePqeP6f4yXf9ul591tJqBqg2TjgpB+ZkTb0bW
uS3HmcGdvF6Up8tS/wFpFRsN+VMAAA==
--------------010900070008010907040109--

--------------enigF5FF44C2CBFAA49ADC82EF21
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.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHi7SuarJ1mMmSrkRAhXkAJ4xiRs7/vThbevj/wzGMYk6R5m7XACeJLc6
Ww37fxskrov+Kek4SeJQzAs=
=WJrU
-----END PGP SIGNATURE-----

--------------enigF5FF44C2CBFAA49ADC82EF21--

From macro@linux-mips.org Wed Sep  7 10:07:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 10:07:39 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:4879 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225239AbVIGJHU>; Wed, 7 Sep 2005 10:07:20 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id D6062F5982; Wed,  7 Sep 2005 11:14:14 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 21160-07; Wed,  7 Sep 2005 11:14:14 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 5A0D3F5980; Wed,  7 Sep 2005 11:14:14 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j879ECgU028397;
	Wed, 7 Sep 2005 11:14:12 +0200
Date:	Wed, 7 Sep 2005 10:14:16 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
In-Reply-To: <20050906184118.GC3102@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
References: <20050907.014234.108739386.anemo@mba.ocn.ne.jp>
 <20050906184118.GC3102@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1067/Wed Sep  7 02:53:51 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8884
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 683
Lines: 16

On Tue, 6 Sep 2005, Ralf Baechle wrote:

> > So, the process can not be kill by SIGKILL.  In 2.6.12, 'sigkill
> > priority fix' was applied to __dequeue_signal(), but it does not help
> > while the SIGTRAP is queued to tsk->pending but SIGKILL (by kill
> > command) is queued to tsk->signal->shared_pending.
> 
> The behaviour of not advancing the EPC beyond the faulting instruction is
> part of the problem - but I believe that was the usual behaviour for
> MIPS UNIXoid operating systems.

 Well, SIGKILL should always work and frankly I can't see a reason to 
return back to user space in the affected context in the first place.  
What's left in EPC shouldn't matter.

  Maciej

From matej.kupljen@ultra.si Wed Sep  7 14:02:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 14:03:09 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:28583 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225250AbVIGNCx>; Wed, 7 Sep 2005 14:02:53 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 0A30DC0AB
	for <linux-mips@linux-mips.org>; Wed,  7 Sep 2005 15:09:43 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id C65E41BC07B
	for <linux-mips@linux-mips.org>; Wed,  7 Sep 2005 15:09:45 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 9BBBC1A18AD
	for <linux-mips@linux-mips.org>; Wed,  7 Sep 2005 15:09:46 +0200 (CEST)
Subject: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	linux-mips@linux-mips.org
Content-Type: text/plain
Date:	Wed, 07 Sep 2005 15:09:44 +0200
Message-Id: <1126098584.12696.19.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8885
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 462
Lines: 20

Hi

Can somebody tell me, what is the right way to make a soft float
toolchain. I tried with crosstool with different flags for configure
and gcc, but the resulting binaries still contains the FP instructions, 
like swc1.

I used --with-float=soft and --nfp for gcc configure,
--without-fp for glibc configure, and compiled glibc
with -msoft-float flag.

Am I missing something, or am I using the wrong flags?

GCC: 3.3.5
GLIBC: 2.3.5
BINUTILS: 2.15

BR,
Matej


From ralf@linux-mips.org Wed Sep  7 14:40:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 14:40:44 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:46087 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225250AbVIGNkX>; Wed, 7 Sep 2005 14:40:23 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j87DlJ1O012197;
	Wed, 7 Sep 2005 14:47:19 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j87DlHR7012196;
	Wed, 7 Sep 2005 14:47:17 +0100
Date:	Wed, 7 Sep 2005 14:47:17 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
Message-ID: <20050907134717.GA3493@linux-mips.org>
References: <20050907.014234.108739386.anemo@mba.ocn.ne.jp> <20050906184118.GC3102@linux-mips.org> <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8886
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1098
Lines: 22

On Wed, Sep 07, 2005 at 10:14:16AM +0100, Maciej W. Rozycki wrote:

> > > So, the process can not be kill by SIGKILL.  In 2.6.12, 'sigkill
> > > priority fix' was applied to __dequeue_signal(), but it does not help
> > > while the SIGTRAP is queued to tsk->pending but SIGKILL (by kill
> > > command) is queued to tsk->signal->shared_pending.
> > 
> > The behaviour of not advancing the EPC beyond the faulting instruction is
> > part of the problem - but I believe that was the usual behaviour for
> > MIPS UNIXoid operating systems.
> 
>  Well, SIGKILL should always work and frankly I can't see a reason to 
> return back to user space in the affected context in the first place.  
> What's left in EPC shouldn't matter.

I said it's part of the problem - not that it should be changed.  The
behaviour as far as I can say is also standard for MIPS unixoid operating
systems.  That said, I definately prefer the approach of Atushi's suggested
fix #2.  The other question is why we try to continue if delivering a
signal failed and we already know that repeated attempts would fail again.

  Ralf

From anemo@mba.ocn.ne.jp Wed Sep  7 14:50:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 14:51:08 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:39911 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225250AbVIGNuu>; Wed, 7 Sep 2005 14:50:50 +0100
Received: from localhost (p5166-ipad204funabasi.chiba.ocn.ne.jp [222.146.92.166])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 2FD53861A; Wed,  7 Sep 2005 22:57:47 +0900 (JST)
Date:	Wed, 07 Sep 2005 22:58:59 +0900 (JST)
Message-Id: <20050907.225859.108306911.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: uninitialized variable in install_sigtramp()
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8887
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 681
Lines: 21

This is a simple fix.  Removing the 'err' variable entirely could be
alternative fix while the return value of install_sigtramp().

Index: arch/mips/kernel/signal-common.h
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/signal-common.h,v
retrieving revision 1.7
diff -u -r1.7 signal-common.h
--- arch/mips/kernel/signal-common.h	14 Jul 2005 12:05:05 -0000	1.7
+++ arch/mips/kernel/signal-common.h	7 Sep 2005 13:38:33 -0000
@@ -182,7 +182,7 @@
 static inline int install_sigtramp(unsigned int __user *tramp,
 	unsigned int syscall)
 {
-	int err;
+	int err = 0;
 
 	/*
 	 * Set up the return code ...
---
Atsushi Nemoto

From ralf@linux-mips.org Wed Sep  7 14:55:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 14:55:50 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:21258 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225258AbVIGNzf>; Wed, 7 Sep 2005 14:55:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j87E2VT5012748;
	Wed, 7 Sep 2005 15:02:31 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j87E2VFq012747;
	Wed, 7 Sep 2005 15:02:31 +0100
Date:	Wed, 7 Sep 2005 15:02:31 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: uninitialized variable in install_sigtramp()
Message-ID: <20050907140231.GB3493@linux-mips.org>
References: <20050907.225859.108306911.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050907.225859.108306911.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8888
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 256
Lines: 8

On Wed, Sep 07, 2005 at 10:58:59PM +0900, Atsushi Nemoto wrote:

> This is a simple fix.  Removing the 'err' variable entirely could be
> alternative fix while the return value of install_sigtramp().

Thanks, I've applied a slightly different fix.

  Ralf

From anemo@mba.ocn.ne.jp Wed Sep  7 15:36:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 15:36:19 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:3067 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225264AbVIGOgE>; Wed, 7 Sep 2005 15:36:04 +0100
Received: from localhost (p5166-ipad204funabasi.chiba.ocn.ne.jp [222.146.92.166])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id CA8C28640; Wed,  7 Sep 2005 23:43:01 +0900 (JST)
Date:	Wed, 07 Sep 2005 23:44:13 +0900 (JST)
Message-Id: <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
To:	ralf@linux-mips.org
Cc:	macro@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050907134717.GA3493@linux-mips.org>
References: <20050906184118.GC3102@linux-mips.org>
	<Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
	<20050907134717.GA3493@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: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8889
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1350
Lines: 33

>>>>> On Wed, 7 Sep 2005 14:47:17 +0100, Ralf Baechle <ralf@linux-mips.org> said:

ralf> That said, I definately prefer the approach of Atushi's
ralf> suggested fix #2.  The other question is why we try to continue
ralf> if delivering a signal failed and we already know that repeated
ralf> attempts would fail again.

The question is for my fix #1 ?

Well, let me explain more.  With that fix, things will go like this:

1.  The "break" instruction raises a exception.
2.  The exception handler queues SIGTRAP(5).
3.  dequeue_signal() dequeue a signal with LOWEST number (i.e. SIGTRAP).
4.  setup_frame() fails due to bad stack pointer and queues SIGSEGV(11).
5.  do_signal() called again (by fix #1)
6.  dequeue_signal() dequeue a signal (i.e. SIGSEGV).
7.  If SIGSEGV did not have a signal handler, default action (coredump
    and exit) is taken.  End.
8.  If SIGSEGV had a signal handler, setup_frame() fails and queues
    SIGSEGV again.  It resets SIGSEGV's handler to SIG_DFL.
9.  returns to user process (pc unchanged).
10.  goto 1.  Then ended at 7.

My fix #2 is more generic approach, but even with the fix, the test
program eats CPU until killed by SIGKILL.  With my fix #1, the test
program will exit immediately.  

So my "which is preferred" question was inappropriate.  I had to ask
"#1 or #2 or both or other ?"

---
Atsushi Nemoto

From sjhill@realitydiluted.com Wed Sep  7 15:47:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 15:47:32 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:30158 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225267AbVIGOrO>; Wed, 7 Sep 2005 15:47:14 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1ED0Ng-0000M8-QH; Wed, 07 Sep 2005 08:54:28 -0500
Subject: Re: MIPS SF toolchain
In-Reply-To: <1126098584.12696.19.camel@localhost.localdomain>
To:	Matej Kupljen <matej.kupljen@ultra.si>
Date:	Wed, 7 Sep 2005 08:54:28 -0500 (CDT)
CC:	linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1ED0Ng-0000M8-QH@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8890
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 494
Lines: 12

> Can somebody tell me, what is the right way to make a soft float
> toolchain. I tried with crosstool with different flags for configure
> and gcc, but the resulting binaries still contains the FP instructions, 
> like swc1.
> 
Here are my RPMS and SRPMS for soft float MIPS toolchains. They are a
bit old, but you can at least see the detailed steps necessary to do
it properly. These use uClibc and not glibc however.

-Steve

ftp://ftp.realitydiluted.com/linux/MIPS/toolchains/uclibc-swfp/

From anemo@mba.ocn.ne.jp Wed Sep  7 15:48:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 15:48:57 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:14803 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225274AbVIGOsk>; Wed, 7 Sep 2005 15:48:40 +0100
Received: from localhost (p5166-ipad204funabasi.chiba.ocn.ne.jp [222.146.92.166])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 420A485BF; Wed,  7 Sep 2005 23:55:37 +0900 (JST)
Date:	Wed, 07 Sep 2005 23:56:49 +0900 (JST)
Message-Id: <20050907.235649.96687998.anemo@mba.ocn.ne.jp>
To:	ralf@linux-mips.org
Cc:	macro@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
References: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
	<20050907134717.GA3493@linux-mips.org>
	<20050907.234413.108737010.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8891
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 571
Lines: 15

>>>>> On Wed, 07 Sep 2005 23:44:13 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> My fix #2 is more generic approach, but even with the fix, the
anemo> test program eats CPU until killed by SIGKILL.  With my fix #1,
anemo> the test program will exit immediately.

Oh, I forgot to say: my fix #1 will not work on 64bit kernel due to
another problem.  I posted a patch for it a few days ago.

http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20050901.011551.96687558.anemo%40mba.ocn.ne.jp

Please apply this first.  Thank you.

---
Atsushi Nemoto

From macro@linux-mips.org Wed Sep  7 16:17:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 16:17:18 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:6407 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225263AbVIGPRB>; Wed, 7 Sep 2005 16:17:01 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 767B6E1C95; Wed,  7 Sep 2005 17:23:56 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 24614-07; Wed,  7 Sep 2005 17:23:56 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id DED49E1C8E; Wed,  7 Sep 2005 17:23:55 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j87FNuwP010594;
	Wed, 7 Sep 2005 17:23:56 +0200
Date:	Wed, 7 Sep 2005 16:24:05 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
In-Reply-To: <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
Message-ID: <Pine.LNX.4.61L.0509071619120.4591@blysk.ds.pg.gda.pl>
References: <20050906184118.GC3102@linux-mips.org>
 <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl> <20050907134717.GA3493@linux-mips.org>
 <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1068/Wed Sep  7 12:03:01 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8892
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 501
Lines: 12

On Wed, 7 Sep 2005, Atsushi Nemoto wrote:

> So my "which is preferred" question was inappropriate.  I had to ask
> "#1 or #2 or both or other ?"

 We should be consistent with other platforms -- having a look at e.g. the 
i386 (as it used to be the reference) and the alpha (as close-enough to 
MIPS) should reveal the answer.  IIRC, a SIGSEGV that has a handler 
installed, but which cannot be callled due to a bad stack pointer is 
forced to SIG_DFL, but you may want to double-check it.

  Maciej

From ddaney@avtrex.com Wed Sep  7 16:26:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 16:26:55 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:35
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225263AbVIGP0k>;
	Wed, 7 Sep 2005 16:26:40 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 7 Sep 2005 08:33:37 -0700
Message-ID: <431F0850.8090804@avtrex.com>
Date:	Wed, 07 Sep 2005 08:33:36 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	linux-mips@linux-mips.org
Subject: Re: MIPS SF toolchain
References: <1126098584.12696.19.camel@localhost.localdomain>
In-Reply-To: <1126098584.12696.19.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2005 15:33:37.0210 (UTC) FILETIME=[83DA29A0:01C5B3C1]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8893
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 910
Lines: 27

Matej Kupljen wrote:
> Hi
> 
> Can somebody tell me, what is the right way to make a soft float
> toolchain. I tried with crosstool with different flags for configure
> and gcc, but the resulting binaries still contains the FP instructions, 
> like swc1.
> 
> I used --with-float=soft and --nfp for gcc configure,
> --without-fp for glibc configure, and compiled glibc
> with -msoft-float flag.
> 
> Am I missing something, or am I using the wrong flags?
> 
> GCC: 3.3.5
> GLIBC: 2.3.5
> BINUTILS: 2.15

On gcc 3.3.x --with-float=soft does nothing.  If you are using a MIPS32 
ISA processor you can configure it with --target=mipsisa32[el]-linux to 
get soft float and MIPS32 ISA by default.

But even better would be to use gcc 3.4.x or 4.0.x where 
--with-float=soft works.  I would also recommend binutils 2.16.1 or 
above as there are some severe bugs in the mips linker in earlier versions.

David Daney.

From ralf@linux-mips.org Wed Sep  7 17:05:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 17:05:25 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:28684 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225263AbVIGQFF>; Wed, 7 Sep 2005 17:05:05 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j87GBvTv017295;
	Wed, 7 Sep 2005 17:11:57 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j87GBvUd017294;
	Wed, 7 Sep 2005 17:11:57 +0100
Date:	Wed, 7 Sep 2005 17:11:57 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
Message-ID: <20050907161157.GA11379@linux-mips.org>
References: <20050906184118.GC3102@linux-mips.org> <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl> <20050907134717.GA3493@linux-mips.org> <20050907.234413.108737010.anemo@mba.ocn.ne.jp> <Pine.LNX.4.61L.0509071619120.4591@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0509071619120.4591@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8894
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 811
Lines: 17

On Wed, Sep 07, 2005 at 04:24:05PM +0100, Maciej W. Rozycki wrote:

> > So my "which is preferred" question was inappropriate.  I had to ask
> > "#1 or #2 or both or other ?"
> 
>  We should be consistent with other platforms -- having a look at e.g. the 
> i386 (as it used to be the reference) and the alpha (as close-enough to 
> MIPS) should reveal the answer.  IIRC, a SIGSEGV that has a handler 
> installed, but which cannot be callled due to a bad stack pointer is 
> forced to SIG_DFL, but you may want to double-check it.

That's what's already happening.  We call force_sigsegv which is like
force_sig unless it's trying to deliver a SIGSEGV in which case it'll
reset the handler to SIG_DFL, return to userspace where it hits the
break instruction and starts all over to process the SIGTRAP.

  Ralf

From macro@linux-mips.org Wed Sep  7 17:27:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Sep 2005 17:28:10 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:46344 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225275AbVIGQ1w>; Wed, 7 Sep 2005 17:27:52 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 27058E1C99; Wed,  7 Sep 2005 18:34:47 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 06872-04; Wed,  7 Sep 2005 18:34:47 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id CD163E1C95; Wed,  7 Sep 2005 18:34:46 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j87GYlE2013441;
	Wed, 7 Sep 2005 18:34:48 +0200
Date:	Wed, 7 Sep 2005 17:34:57 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
In-Reply-To: <20050907161157.GA11379@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0509071731320.4591@blysk.ds.pg.gda.pl>
References: <20050906184118.GC3102@linux-mips.org>
 <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl> <20050907134717.GA3493@linux-mips.org>
 <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
 <Pine.LNX.4.61L.0509071619120.4591@blysk.ds.pg.gda.pl>
 <20050907161157.GA11379@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1068/Wed Sep  7 12:03:01 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8895
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 479
Lines: 12

On Wed, 7 Sep 2005, Ralf Baechle wrote:

> That's what's already happening.  We call force_sigsegv which is like
> force_sig unless it's trying to deliver a SIGSEGV in which case it'll
> reset the handler to SIG_DFL, return to userspace where it hits the
> break instruction and starts all over to process the SIGTRAP.

 Except that SIG_DFL for SIGSEGV is killing the process (with a core 
dump).  Therefore user space shouldn't ever be reached again in this 
context.

  Maciej

From matej.kupljen@ultra.si Thu Sep  8 09:34:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 09:34:19 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:56979 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8224834AbVIHIeC>; Thu, 8 Sep 2005 09:34:02 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id A2777BFE2;
	Thu,  8 Sep 2005 10:41:00 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id 31E2D1BC085;
	Thu,  8 Sep 2005 10:41:03 +0200 (CEST)
Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52])
	by smtp.triera.net (Postfix) with ESMTP id 6E61B1A18AA;
	Thu,  8 Sep 2005 10:41:02 +0200 (CEST)
Subject: Re: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	David Daney <ddaney@avtrex.com>
Cc:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <431F0850.8090804@avtrex.com>
References: <1126098584.12696.19.camel@localhost.localdomain>
	 <431F0850.8090804@avtrex.com>
Content-Type: text/plain
Organization: Ultra d.o.o.
Date:	Thu, 08 Sep 2005 10:41:06 +0200
Message-Id: <1126168866.25388.11.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8896
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 1882
Lines: 54

Hi

> On gcc 3.3.x --with-float=soft does nothing.  If you are using a MIPS32 
> ISA processor you can configure it with --target=mipsisa32[el]-linux to 
> get soft float and MIPS32 ISA by default.

O.K.
Thank you for the explanation.

> But even better would be to use gcc 3.4.x or 4.0.x where 
> --with-float=soft works.  I would also recommend binutils 2.16.1 or 
> above as there are some severe bugs in the mips linker in earlier versions.

O.K.
Yesterday I tried with the gcc 3.4.3, glibc 2.3.5 and binutils 2.16.1.
libgcc.a looks O.K, because I did not find any FP instruction, however
if I do objdump on libc.so.6, I get:

0002ff70 <__sigsetjmp_aux>:
   2ff70:       3c1c0017        lui     gp,0x17
   2ff74:       279cce30        addiu   gp,gp,-12752
   2ff78:       0399e021        addu    gp,gp,t9
   2ff7c:       00801021        move    v0,a0
   2ff80:       e4940038        swc1    $f20,56(a0)
   2ff84:       e495003c        swc1    $f21,60(a0)
   2ff88:       e4960040        swc1    $f22,64(a0)
   2ff8c:       e4970044        swc1    $f23,68(a0)
   2ff90:       e4980048        swc1    $f24,72(a0)
   2ff94:       e499004c        swc1    $f25,76(a0)
   2ff98:       e49a0050        swc1    $f26,80(a0)
   2ff9c:       e49b0054        swc1    $f27,84(a0)
   2ffa0:       e49c0058        swc1    $f28,88(a0)
   2ffa4:       e49d005c        swc1    $f29,92(a0)
   2ffa8:       e49e0060        swc1    $f30,96(a0)
   2ffac:       e49f0064        swc1    $f31,100(a0)
   2ffb0:       ac9f0000        sw      ra,0(a0)
   2ffb4:       ac860004        sw      a2,4(a0)
   2ffb8:       ac870028        sw      a3,40(a0)

Again, FP instructions! I don't know what is wrong :-(

Now I am trying with the:
GCC: 4.1.0
GLIBC: 2.3.5
BINUTILS: 2.16.1
Linux Headers: 2.6.11

Will let you know, when the toolchain is built.

BR,
Matej

P.S.: I am cc-ing crosstool mailing list too.


From matej.kupljen@ultra.si Thu Sep  8 12:26:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 12:26:31 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:15532 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225072AbVIHL0P>; Thu, 8 Sep 2005 12:26:15 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id B6349BFF9;
	Thu,  8 Sep 2005 13:33:12 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id BBCE11BC086;
	Thu,  8 Sep 2005 13:33:15 +0200 (CEST)
Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52])
	by smtp.triera.net (Postfix) with ESMTP id 5C2F11A18A7;
	Thu,  8 Sep 2005 13:33:15 +0200 (CEST)
Subject: Re: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	David Daney <ddaney@avtrex.com>
Cc:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <1126168866.25388.11.camel@orionlinux.starfleet.com>
References: <1126098584.12696.19.camel@localhost.localdomain>
	 <431F0850.8090804@avtrex.com>
	 <1126168866.25388.11.camel@orionlinux.starfleet.com>
Content-Type: text/plain
Organization: Ultra d.o.o.
Date:	Thu, 08 Sep 2005 13:33:19 +0200
Message-Id: <1126179199.25389.20.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8897
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 4416
Lines: 108

Hi

> Now I am trying with the:
> GCC: 4.1.0
> GLIBC: 2.3.5
> BINUTILS: 2.16.1
> Linux Headers: 2.6.11

Here are the results:
ligcc.a does not have any sf instructions.
busybox built as dynamic binary does not have any sf ins.
libc.so.6 has this:

-------------------------------------------------------------
0002fe80 <__longjmp>:
   2fe80:       c4940038        lwc1    $f20,56(a0)
   2fe84:       c495003c        lwc1    $f21,60(a0)
   2fe88:       c4960040        lwc1    $f22,64(a0)
   2fe8c:       c4970044        lwc1    $f23,68(a0)
   2fe90:       c4980048        lwc1    $f24,72(a0)
   2fe94:       c499004c        lwc1    $f25,76(a0)
   2fe98:       c49a0050        lwc1    $f26,80(a0)
   2fe9c:       c49b0054        lwc1    $f27,84(a0)
   2fea0:       c49c0058        lwc1    $f28,88(a0)
   2fea4:       c49d005c        lwc1    $f29,92(a0)
   2fea8:       c49e0060        lwc1    $f30,96(a0)
   2feac:       c49f0064        lwc1    $f31,100(a0)
   2feb0:       8c820030        lw      v0,48(a0)
   2feb4:       00000000        nop
   2feb8:       44c2f800        ctc1    v0,$31
   2febc:       8c9c002c        lw      gp,44(a0)
   2fec0:       8c900008        lw      s0,8(a0)
   2fec4:       8c91000c        lw      s1,12(a0)
   2fec8:       8c920010        lw      s2,16(a0)
   2fecc:       8c930014        lw      s3,20(a0)
   2fed0:       8c940018        lw      s4,24(a0)
   2fed4:       8c95001c        lw      s5,28(a0)
   2fed8:       8c960020        lw      s6,32(a0)
   2fedc:       8c970024        lw      s7,36(a0)
   2fee0:       8c990000        lw      t9,0(a0)
   2fee4:       8c9d0004        lw      sp,4(a0)
   2fee8:       8c9e0028        lw      s8,40(a0)
   2feec:       14a00005        bnez    a1,2ff04 <__longjmp+0x84>
   2fef0:       00000000        nop
   2fef4:       03200008        jr      t9
   2fef8:       24020001        li      v0,1
   2fefc:       1000ffff        b       2fefc <__longjmp+0x7c>
   2ff00:       00000000        nop
   2ff04:       03200008        jr      t9
   2ff08:       00a01021        move    v0,a1
   2ff0c:       1000fffb        b       2fefc <__longjmp+0x7c>
   2ff10:       00000000        nop
-------------------------------------------------------------
and
-------------------------------------------------------------
0002ff70 <__sigsetjmp_aux>:
   2ff70:       3c1c0017        lui     gp,0x17
   2ff74:       279cce40        addiu   gp,gp,-12736
   2ff78:       0399e021        addu    gp,gp,t9
   2ff7c:       00801021        move    v0,a0
   2ff80:       e4940038        swc1    $f20,56(a0)
   2ff84:       e495003c        swc1    $f21,60(a0)
   2ff88:       e4960040        swc1    $f22,64(a0)
   2ff8c:       e4970044        swc1    $f23,68(a0)
   2ff90:       e4980048        swc1    $f24,72(a0)
   2ff94:       e499004c        swc1    $f25,76(a0)
   2ff98:       e49a0050        swc1    $f26,80(a0)
   2ff9c:       e49b0054        swc1    $f27,84(a0)
   2ffa0:       e49c0058        swc1    $f28,88(a0)
   2ffa4:       e49d005c        swc1    $f29,92(a0)
   2ffa8:       e49e0060        swc1    $f30,96(a0)
   2ffac:       e49f0064        swc1    $f31,100(a0)
   2ffb0:       ac9f0000        sw      ra,0(a0)
   2ffb4:       ac860004        sw      a2,4(a0)
   2ffb8:       ac870028        sw      a3,40(a0)
   2ffbc:       ac9c002c        sw      gp,44(a0)
   2ffc0:       ac900008        sw      s0,8(a0)
   2ffc4:       ac91000c        sw      s1,12(a0)
   2ffc8:       ac920010        sw      s2,16(a0)
   2ffcc:       ac930014        sw      s3,20(a0)
   2ffd0:       ac940018        sw      s4,24(a0)
   2ffd4:       ac95001c        sw      s5,28(a0)
   2ffd8:       ac960020        sw      s6,32(a0)
   2ffdc:       ac970024        sw      s7,36(a0)
   2ffe0:       8f9982a8        lw      t9,-32088(gp)
   2ffe4:       4443f800        cfc1    v1,$31
   2ffe8:       03200008        jr      t9
   2ffec:       ac430030        sw      v1,48(v0)
-------------------------------------------------------------

I did:
mipsel-linux-objdump -S libc.so.6 | less 
and then searching for $f (floating point registers)

If I link busybox static, I get those two functions linked in.

How to solve this?

One more thing.
I can compile strace only with gcc-3.3.4. With any other version
I get:
syscall.c:449: error: 'SYS_read' undeclared (first use in this function)

I applayed the patch for this, but it doesn't seem to help.

BR,
Matej


From matej.kupljen@ultra.si Thu Sep  8 13:14:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 13:15:15 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:36018 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225072AbVIHMOz>; Thu, 8 Sep 2005 13:14:55 +0100
Received: from localhost (in-3.mx.triera.net [213.161.0.27])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id A3545C006;
	Thu,  8 Sep 2005 14:21:53 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-3.mx.triera.net (Postfix) with SMTP id E4C941BC084;
	Thu,  8 Sep 2005 14:21:56 +0200 (CEST)
Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52])
	by smtp.triera.net (Postfix) with ESMTP id 18A571A18A9;
	Thu,  8 Sep 2005 14:21:57 +0200 (CEST)
Subject: Re: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	David Daney <ddaney@avtrex.com>
Cc:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <1126179199.25389.20.camel@orionlinux.starfleet.com>
References: <1126098584.12696.19.camel@localhost.localdomain>
	 <431F0850.8090804@avtrex.com>
	 <1126168866.25388.11.camel@orionlinux.starfleet.com>
	 <1126179199.25389.20.camel@orionlinux.starfleet.com>
Content-Type: text/plain
Organization: Ultra d.o.o.
Date:	Thu, 08 Sep 2005 14:22:02 +0200
Message-Id: <1126182122.25393.27.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8898
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 744
Lines: 31

Hi

I think I found the problem.

> -------------------------------------------------------------
> 0002fe80 <__longjmp>:
>    2fe80:       c4940038        lwc1    $f20,56(a0)
>    2fe84:       c495003c        lwc1    $f21,60(a0)
....

This code is written in  sysdeps/mips/setjmp_aux.c in 
inline assembly.

> and
> -------------------------------------------------------------
> 0002ff70 <__sigsetjmp_aux>:
>    2ff70:       3c1c0017        lui     gp,0x17
>    2ff74:       279cce40        addiu   gp,gp,-12736

This code is written in sysdeps/mips/__longjmp.c in 
inline assembly.

> How to solve this?

Because I am using sf, there is no need to store those
registers, or is it?
Can I just #ifdef this code if compiled for sf?

BR,
Matej


From ralf@linux-mips.org Thu Sep  8 13:22:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 13:22:50 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:48922 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225072AbVIHMWf>; Thu, 8 Sep 2005 13:22:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j88CTYLW013694;
	Thu, 8 Sep 2005 13:29:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j88CTX1j013693;
	Thu, 8 Sep 2005 13:29:33 +0100
Date:	Thu, 8 Sep 2005 13:29:33 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Matej Kupljen <matej.kupljen@ultra.si>
Cc:	David Daney <ddaney@avtrex.com>, crossgcc@sources.redhat.com,
	linux-mips@linux-mips.org
Subject: Re: MIPS SF toolchain
Message-ID: <20050908122933.GC3608@linux-mips.org>
References: <1126098584.12696.19.camel@localhost.localdomain> <431F0850.8090804@avtrex.com> <1126168866.25388.11.camel@orionlinux.starfleet.com> <1126179199.25389.20.camel@orionlinux.starfleet.com> <1126182122.25393.27.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1126182122.25393.27.camel@orionlinux.starfleet.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8899
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 726
Lines: 22

On Thu, Sep 08, 2005 at 02:22:02PM +0200, Matej Kupljen wrote:

> > and
> > -------------------------------------------------------------
> > 0002ff70 <__sigsetjmp_aux>:
> >    2ff70:       3c1c0017        lui     gp,0x17
> >    2ff74:       279cce40        addiu   gp,gp,-12736
> 
> This code is written in sysdeps/mips/__longjmp.c in 
> inline assembly.
> 
> > How to solve this?
> 
> Because I am using sf, there is no need to store those
> registers, or is it?
> Can I just #ifdef this code if compiled for sf?

Why not just letting the kernel fp emulator do the job?  On the average
fpu-less system fp performance doesn't matter, so the impact of the
kernel fp emulator is much less than the pain of avoiding it.

  Ralf

From vasanth@aelixsystems.com Thu Sep  8 14:48:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 14:49:06 +0100 (BST)
Received: from xmail05.myhosting.com ([IPv6:::ffff:168.144.250.219]:8877 "EHLO
	xmail05.myhosting.com") by linux-mips.org with ESMTP
	id <S8225273AbVIHNsq>; Thu, 8 Sep 2005 14:48:46 +0100
Received: (qmail 22295 invoked from network); 8 Sep 2005 13:55:40 -0000
Received: from unknown (HELO vasanth) (Authenticated-user:_vasanth@aelixsystems.com@[59.92.141.41])
          (envelope-sender <vasanth@aelixsystems.com>)
          by xmail05.myhosting.com (qmail-ldap-1.03) with SMTP
          for <linux-mips@linux-mips.org>; 8 Sep 2005 13:55:39 -0000
Message-ID: <005201c5b47d$20a0d4d0$3c00a8c0@vasanth>
From:	"vasanth" <vasanth@aelixsystems.com>
To:	<linux-mips@linux-mips.org>
Subject: unresolved symbol
Date:	Thu, 8 Sep 2005 19:26:17 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004F_01C5B4AB.2F2C0AF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <vasanth@aelixsystems.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8900
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vasanth@aelixsystems.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2281
Lines: 66

This is a multi-part message in MIME format.

------=_NextPart_000_004F_01C5B4AB.2F2C0AF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am getting the folowing error message when i do insmod .
insmod: unresolved symbol __udelay
insmod: unresolved symbol atomic_add
insmod: unresolved symbol atomic_sub

I complied the driver code for mips processor using the folowing command
mips-linux-gcc -G O -mno-abicalls -fno-pic -pipe -mtune=3D4kc -mips32 -c =
lcddriver.c -I/mykernel/include
It is compiling without any error .=20
Can anybody know how to solve this problem.?

Regards,
Vasanth.
------=_NextPart_000_004F_01C5B4AB.2F2C0AF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Courier New" size=3D3>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I&nbsp;am getting&nbsp;the folowing =
error message=20
when i do&nbsp;insmod .</FONT></DIV>
<DIV>insmod: unresolved symbol __udelay<BR>insmod: unresolved symbol=20
atomic_add</DIV>
<DIV>insmod: unresolved symbol atomic_sub</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I&nbsp;complied the driver code for =
mips processor=20
using the folowing command</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mips-linux-gcc -G O -mno-abicalls =
-fno-pic -pipe=20
-mtune=3D4kc -mips32 -c lcddriver.c -I/mykernel/include</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It is compiling without any error . =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can anybody&nbsp;know how to solve this =

problem.?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT></FONT></FONT><FONT face=3DArial =

size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>Vasanth.</DIV></DIV></FONT></BODY></HTML>

------=_NextPart_000_004F_01C5B4AB.2F2C0AF0--



From dank@kegel.com Thu Sep  8 14:55:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 14:55:27 +0100 (BST)
Received: from relay01.pair.com ([IPv6:::ffff:209.68.5.15]:56081 "HELO
	relay01.pair.com") by linux-mips.org with SMTP id <S8225273AbVIHNzF>;
	Thu, 8 Sep 2005 14:55:05 +0100
Received: (qmail 885 invoked from network); 8 Sep 2005 14:02:08 -0000
Received: from unknown (HELO ?192.168.123.1?) (unknown)
  by unknown with SMTP; 8 Sep 2005 14:02:08 -0000
X-pair-Authenticated: 24.126.76.52
Message-ID: <43204123.8000204@kegel.com>
Date:	Thu, 08 Sep 2005 06:48:19 -0700
From:	Dan Kegel <dank@kegel.com>
User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98)
X-Accept-Language: en, de-de
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	David Daney <ddaney@avtrex.com>, crossgcc@sources.redhat.com,
	linux-mips@linux-mips.org
Subject: Re: MIPS SF toolchain
References: <1126098584.12696.19.camel@localhost.localdomain>	 <431F0850.8090804@avtrex.com>	 <1126168866.25388.11.camel@orionlinux.starfleet.com>	 <1126179199.25389.20.camel@orionlinux.starfleet.com> <1126182122.25393.27.camel@orionlinux.starfleet.com>
In-Reply-To: <1126182122.25393.27.camel@orionlinux.starfleet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dank@kegel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8901
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dank@kegel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 797
Lines: 33

Matej Kupljen wrote:
> I think I found the problem.
> 
> ....
> 
> This code is written in  sysdeps/mips/setjmp_aux.c in 
> inline assembly.  ...
> 
> This code is written in sysdeps/mips/__longjmp.c in 
> inline assembly.
> 
> Because I am using sf, there is no need to store those
> registers, or is it?
> Can I just #ifdef this code if compiled for sf?

Other architectures do things like this, e.g.

sysdeps/powerpc/powerpc32/__longjmp-common.S:#ifdef __NO_VMX__

so I don't see why not.

In fact, I had to do something similar once to make life
possible for ppc405.  See

http://kegel.com/xgcc3/glibc-ppc-nofpu.patch3

(Hmm, wonder if something like that ever made it in to
mainline glibc.)

- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

From ralf@linux-mips.org Thu Sep  8 14:58:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 14:58:57 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:9227 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225273AbVIHN6l>; Thu, 8 Sep 2005 14:58:41 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j88E5F3o017201;
	Thu, 8 Sep 2005 15:05:15 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j88E5EaM017200;
	Thu, 8 Sep 2005 15:05:14 +0100
Date:	Thu, 8 Sep 2005 15:05:13 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	vasanth <vasanth@aelixsystems.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: unresolved symbol
Message-ID: <20050908140513.GD3608@linux-mips.org>
References: <005201c5b47d$20a0d4d0$3c00a8c0@vasanth>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005201c5b47d$20a0d4d0$3c00a8c0@vasanth>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8902
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 546
Lines: 15

On Thu, Sep 08, 2005 at 07:26:17PM +0530, vasanth wrote:

> I am getting the folowing error message when i do insmod .
> insmod: unresolved symbol __udelay
> insmod: unresolved symbol atomic_add
> insmod: unresolved symbol atomic_sub
> 
> I complied the driver code for mips processor using the folowing command
> mips-linux-gcc -G O -mno-abicalls -fno-pic -pipe -mtune=4kc -mips32 -c lcddriver.c -I/mykernel/include
> It is compiling without any error . 

Use -O2.  In fact use _exactly_ the same options as for the kernel build
itself.

  Ralf

From ddaney@avtrex.com Thu Sep  8 16:22:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 16:22:20 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:43543
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225304AbVIHPWA>;
	Thu, 8 Sep 2005 16:22:00 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 8 Sep 2005 08:29:05 -0700
Message-ID: <432058C1.80106@avtrex.com>
Date:	Thu, 08 Sep 2005 08:29:05 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: MIPS SF toolchain
References: <1126098584.12696.19.camel@localhost.localdomain>	 <431F0850.8090804@avtrex.com>	 <1126168866.25388.11.camel@orionlinux.starfleet.com>	 <1126179199.25389.20.camel@orionlinux.starfleet.com> <1126182122.25393.27.camel@orionlinux.starfleet.com>
In-Reply-To: <1126182122.25393.27.camel@orionlinux.starfleet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Sep 2005 15:29:05.0691 (UTC) FILETIME=[0C6D66B0:01C5B48A]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8903
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1443
Lines: 48

Matej Kupljen wrote:
> Hi
> 
> I think I found the problem.
> 
> 
>>-------------------------------------------------------------
>>0002fe80 <__longjmp>:
>>   2fe80:       c4940038        lwc1    $f20,56(a0)
>>   2fe84:       c495003c        lwc1    $f21,60(a0)
> 
> ....
> 
> This code is written in  sysdeps/mips/setjmp_aux.c in 
> inline assembly.
> 
> 
>>and
>>-------------------------------------------------------------
>>0002ff70 <__sigsetjmp_aux>:
>>   2ff70:       3c1c0017        lui     gp,0x17
>>   2ff74:       279cce40        addiu   gp,gp,-12736
> 
> 
> This code is written in sysdeps/mips/__longjmp.c in 
> inline assembly.
> 
> 
>>How to solve this?
> 
> 
> Because I am using sf, there is no need to store those
> registers, or is it?
> Can I just #ifdef this code if compiled for sf?
> 

I do have some patches for glibc to get rid of these in a soft float 
build.  However as Ralf Baechle said in the other message, the kernel FP 
emulator works and is not that large of an overhead.

The reason I did the glibc patch was that some IDT processor/linux 
kernel combination I was using was broken WRT the FP emulator.  I 
suppose if you had a lot of code doing setjump (like C++ code with 
exeception handling that uses setjump/longjump as would be obtained with 
uClibc) than this would be bad.  But since you are using glibc, the 
tools will be using DWARF exception handling and it is not really an issue.

David Daney.

From drow@nevyn.them.org Thu Sep  8 16:26:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 16:26:50 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:16283 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225304AbVIHP0d>;
	Thu, 8 Sep 2005 16:26:33 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EDOPB-0005PQ-OF; Thu, 08 Sep 2005 11:33:37 -0400
Date:	Thu, 8 Sep 2005 11:33:37 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	vasanth <vasanth@aelixsystems.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: unresolved symbol
Message-ID: <20050908153337.GA20775@nevyn.them.org>
References: <005201c5b47d$20a0d4d0$3c00a8c0@vasanth>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005201c5b47d$20a0d4d0$3c00a8c0@vasanth>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8904
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 575
Lines: 18

On Thu, Sep 08, 2005 at 07:26:17PM +0530, vasanth wrote:
> Hi,
> 
> I am getting the folowing error message when i do insmod .
> insmod: unresolved symbol __udelay
> insmod: unresolved symbol atomic_add
> insmod: unresolved symbol atomic_sub
> 
> I complied the driver code for mips processor using the folowing command
> mips-linux-gcc -G O -mno-abicalls -fno-pic -pipe -mtune=4kc -mips32 -c lcddriver.c -I/mykernel/include
> It is compiling without any error . 
> Can anybody know how to solve this problem.?

Turn on optimization.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From dank@kegel.com Thu Sep  8 18:27:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 18:27:39 +0100 (BST)
Received: from 216-239-45-4.google.com ([IPv6:::ffff:216.239.45.4]:11195 "EHLO
	216-239-45-4.google.com") by linux-mips.org with ESMTP
	id <S8225304AbVIHR1W>; Thu, 8 Sep 2005 18:27:22 +0100
Received: from [172.29.52.41] (dank.smo.corp.google.com [172.29.52.41])
	by vegeta.corp.google.com with ESMTP id j88HXriU026558;
	Thu, 8 Sep 2005 10:33:53 -0700
Message-ID: <43207601.7020000@kegel.com>
Date:	Thu, 08 Sep 2005 10:33:53 -0700
From:	Daniel Kegel <dank@kegel.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	gcc@gcc.gnu.org, Jonathan Day <imipak@yahoo.com>
CC:	linux-mips@linux-mips.org, crossgcc <crossgcc@sources.redhat.com>
Subject: Re: Question regarding compiling a toolchain for a Broadcom SB1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dank@kegel.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8905
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dank@kegel.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1194
Lines: 29

Jonathan Day <imipak at yahoo dot com> wrote:
> Crosstool, for example, only supports 32-bit MIPS -
> and even then the build matrix is a pretty shade of
> red for the most part.

[ The build matrix: http://kegel.com/crosstool/current/buildlogs/ ]

There are quite a few combinations that build for 32-bit mips with crosstool, e.g.
  mips-gcc-3.2.3-glibc-2.2.5
  mips-gcc-3.2.3-glibc-2.3.2
  mips-gcc-3.3.6-glibc-2.2.5
  mips-gcc-3.3.6-glibc-2.3.5
  mips-gcc-3.4.4-glibc-2.3.2-hdrs-2.6.11.2
  mips-gcc-3.4.4-glibc-2.3.5-hdrs-2.6.11.2
  mips-gcc-4.1-20050702-glibc-2.3.2-hdrs-2.6.11.2
  mips-gcc-4.1-20050709-glibc-2.3.2-hdrs-2.6.11.2
so the situation isn't that dire.

For the record, I would be more than happy to add mips64 support to crosstool.
http://www.linux-mips.org/archives/linux-mips/2005-07/msg00189.html
http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/glibc.html
http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/gcc-final.html
mentions some patches that might be needed.
I haven't had time to chase them down and add them to crosstool,
but if anybody else felt like it, I'd gladly accept the patches.
I'm sure a lot of mips64 users would be very happy.
- Dan



From imipak@yahoo.com Thu Sep  8 22:05:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Sep 2005 22:05:42 +0100 (BST)
Received: from web31502.mail.mud.yahoo.com ([IPv6:::ffff:68.142.198.131]:58811
	"HELO web31502.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225329AbVIHVFV>; Thu, 8 Sep 2005 22:05:21 +0100
Received: (qmail 86770 invoked by uid 60001); 8 Sep 2005 21:11:27 -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=zt1rjVqh9MZpv+iz+iBrfRHlONHP9H9BZhA/KNkpMMpfCMPeWGanZ/hwuLMWGn2ojkNf8Z8F+54sEVG9cbQhaQGZweDtsNQN1NSTqM5A839hV5c9XDVfv+jyMrmtjVPoqERU1FZN41sX5bRyL3Kq2C2nuCSrYGXVVM36G+sOirE=  ;
Message-ID: <20050908211127.86768.qmail@web31502.mail.mud.yahoo.com>
Received: from [208.187.37.98] by web31502.mail.mud.yahoo.com via HTTP; Thu, 08 Sep 2005 14:11:26 PDT
Date:	Thu, 8 Sep 2005 14:11:26 -0700 (PDT)
From:	Jonathan Day <imipak@yahoo.com>
Subject: Re: Question regarding compiling a toolchain for a Broadcom SB1
To:	Daniel Kegel <dank@kegel.com>, gcc@gcc.gnu.org
Cc:	linux-mips@linux-mips.org, crossgcc <crossgcc@sources.redhat.com>
In-Reply-To: <43207601.7020000@kegel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <imipak@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8906
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: imipak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2483
Lines: 79

Here's the web link to all of the patches needed by
the Linux From Scratch group.

http://documents.jg555.com/cross-lfs/mips64-64/materials/patches.html

I'm doing a build from the binutils, gcc and glibc
from CVS, for an initial run. Results so far:

Binutils patches cleanly, using the patch on file. It
seems to build fine, when patched, but until all
stages are complete, there's no easy way to verify
that.

GCC won't take the Posix patch and some of the other
patches need massaging, but there doesn't seem to be
any major problems. HOWEVER, this does say that you'd
best stick with the intended version (GCC 4.0.1) for
your build scripts.

Glibc will take the 64-bit fixes but all other patches
are rejected. It failed on the forced unwinding test,
when configuring. According to the LFS docs, NPTL is
broken for MIPS64, but I don't know if that is still
the case. I decided to backtrack to the glibc that
works, according to the LFS, and have classed the
status of Glibc for MIPS64 as uncertain.


--- Daniel Kegel <dank@kegel.com> wrote:

> Jonathan Day <imipak at yahoo dot com> wrote:
> > Crosstool, for example, only supports 32-bit MIPS
> -
> > and even then the build matrix is a pretty sh
ade
> of
> > red for the most part.
> 
> [ The build matrix:
> http://kegel.com/crosstool/current/buildlogs/ ]
> 
> There are quite a few combinations that build for
> 32-bit mips with crosstool, e.g.
>   mips-gcc-3.2.3-glibc-2.2.5
>   mips-gcc-3.2.3-glibc-2.3.2
>   mips-gcc-3.3.6-glibc-2.2.5
>   mips-gcc-3.3.6-glibc-2.3.5
>   mips-gcc-3.4.4-glibc-2.3.2-hdrs-2.6.11.2
>   mips-gcc-3.4.4-glibc-2.3.5-hdrs-2.6.11.2
>   mips-gcc-4.1-20050702-glibc-2.3.2-hdrs-2.6.11.2
>   mips-gcc-4.1-20050709-glibc-2.3.2-hdrs-2.6.11.2
> so the situation isn't that dire.
> 
> For the record, I would be more than happy to add
> mips64 support to crosstool.
>
http://www.linux-mips.org/archives/linux-mips/2005-07/msg00189.html
>
http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/glibc.html
>
http://documents.jg555.com/cross-lfs/mips64-64/cross-tools/gcc-final.html
> mentions some patches that might be needed.
> I haven't had time to chase them down and add them
> to crosstool,
> but if anybody else felt like it, I'd gladly accept
> the patches.
> I'm sure a lot of mips64 users would be very happy.
> - Dan
> 
> 
> 



	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

From Vadivelan@soc-soft.com Fri Sep  9 05:48:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 05:49:18 +0100 (BST)
Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:54534 "EHLO
	IGateway.soc-soft.com") by linux-mips.org with ESMTP
	id <S8224771AbVIIEs5> convert rfc822-to-8bit; Fri, 9 Sep 2005 05:48:57 +0100
Received: from keys.soc-soft.com ([192.168.4.44]) by IGateway.soc-soft.com with InterScan VirusWall; Fri, 09 Sep 2005 10:25:58 +0530
Received: from soc-mail.soc-soft.com ([192.168.4.25])
  by keys.soc-soft.com (PGP Universal service);
  Fri, 09 Sep 2005 10:25:58 +0530
X-PGP-Universal: processed;
	by keys.soc-soft.com on Fri, 09 Sep 2005 10:25:58 +0530
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: scheduling with irqs disabled: init
Date:	Fri, 9 Sep 2005 10:25:55 +0530
Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902CD345ED@soc-mail.soc-soft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: scheduling with irqs disabled: init
Thread-Index: AcW09tD3uRIN0t9zQK+xtIPZXLXMnwAAoeAw
From:	<Vadivelan@soc-soft.com>
To:	<linux-mips@linux-mips.org>
Return-Path: <Vadivelan@soc-soft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8908
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Vadivelan@soc-soft.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1733
Lines: 47


hi,
	I'm porting MVL4.0 kernel on to a mips board. I've been getting
a call trace as follows.

BUG: scheduling with irqs disabled: init/0x00000000/1
caller is schedule_timeout+0x84/0xe8
Call Trace:
 [<8030a0a8>] schedule_timeout+0x84/0xe8
 [<803090b8>] schedule+0x114/0x160
 [<803090b0>] schedule+0x10c/0x160
 [<8030a0a8>] schedule_timeout+0x84/0xe8
 [<80132610>] process_timeout+0x0/0x8
 [<80132c0c>] msleep_interruptible+0x4c/0x70
 [<802300a8>] gs_wait_tx_flushed+0x1fc/0x3b0
 [<8022fc44>] gs_write+0x25c/0x264
 [<802310cc>] gs_close+0x260/0x394
 [<80216364>] tty_fasync+0x8c/0x134
 [<80216b00>] release_dev+0x6f4/0xa08
 [<8021dddc>] write_chan+0x420/0x48c
 [<8012107c>] __wake_up+0x44/0x80
 [<80120f58>] default_wake_function+0x0/0x28
 [<8017a734>] get_empty_filp+0x64/0x13c
 [<80215234>] tty_ldisc_deref+0xcc/0x110
 [<80215b28>] tty_write+0x2bc/0x454
 [<80216e24>] tty_release+0x10/0x20
 [<80179988>] vfs_write+0xac/0x114
 [<8017aacc>] __fput+0x298/0x2d0
 [<8018e9b8>] getname+0x28/0xfc
 [<80178d2c>] filp_close+0x54/0xb4
 [<80178d24>] filp_close+0x4c/0xb4
 [<8010bc64>] stack_done+0x20/0x3c

I'm totally unaware of the bug. Can anyone help me fix it?

Thanking u in advance,

vadi.


The information contained in this e-mail message and in any annexure is
confidential to the  recipient and may contain privileged information. If you are not
the intended recipient, please notify the sender and delete the message along with
any annexure. You should not disclose, copy or otherwise use the information contained
in the message or any annexure. Any views expressed in this e-mail are those of the
individual sender except where the sender specifically states them to be the views of
SoCrates Software India Pvt Ltd., Bangalore.

From matej.kupljen@ultra.si Fri Sep  9 07:41:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 07:41:48 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:55692 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8224951AbVIIGl2>; Fri, 9 Sep 2005 07:41:28 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 202C2C035;
	Fri,  9 Sep 2005 08:48:33 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id 527131BC07E;
	Fri,  9 Sep 2005 08:48:34 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id B3B631A18A7;
	Fri,  9 Sep 2005 08:48:33 +0200 (CEST)
Subject: Re: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	David Daney <ddaney@avtrex.com>
Cc:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <432058C1.80106@avtrex.com>
References: <1126098584.12696.19.camel@localhost.localdomain>
	 <431F0850.8090804@avtrex.com>
	 <1126168866.25388.11.camel@orionlinux.starfleet.com>
	 <1126179199.25389.20.camel@orionlinux.starfleet.com>
	 <1126182122.25393.27.camel@orionlinux.starfleet.com>
	 <432058C1.80106@avtrex.com>
Content-Type: text/plain
Date:	Fri, 09 Sep 2005 08:48:22 +0200
Message-Id: <1126248502.20058.5.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8909
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 681
Lines: 25

Hi

> > Can I just #ifdef this code if compiled for sf?
> > 
> 
> I do have some patches for glibc to get rid of these in a soft float 
> build.  

Can I see these patches, please?
(What is the #define for the FP?)

> However as Ralf Baechle said in the other message, the kernel FP 
> emulator works and is not that large of an overhead.

I also removed the FP Emulator in the kernel, just to be sure that
no SF ins are executed (I can send the patch to the list, but I know
there has already been discussion about this).

IMHO, if we say that we have a SF toolchain then there MUST NOT
BE any SF ins, otherwise we have a "semi soft float" toolchain.
Don't you agree?

BR,
Matej


From tnt@246tNt.com Fri Sep  9 08:20:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 08:21:19 +0100 (BST)
Received: from outmx015.isp.belgacom.be ([IPv6:::ffff:195.238.2.87]:37550 "EHLO
	outmx015.isp.belgacom.be") by linux-mips.org with ESMTP
	id <S8224987AbVIIHUy>; Fri, 9 Sep 2005 08:20:54 +0100
Received: from outmx015.isp.belgacom.be (localhost [127.0.0.1])
        by outmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j897RuM7010943
        for <linux-mips@linux-mips.org>; Fri, 9 Sep 2005 09:27:56 +0200
        (envelope-from <tnt@246tNt.com>)
Received: from ayanami.246tNt.com (21-156.245.81.adsl.skynet.be [81.245.156.21])
        by outmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j897Rlgm010843;
	Fri, 9 Sep 2005 09:27:47 +0200
        (envelope-from <tnt@246tNt.com>)
Received: from [10.0.0.245] (246tNt-laptop.lan.ayanami.246tNt.com [10.0.0.245])
	by ayanami.246tNt.com (Postfix) with ESMTP id 9B32510E7BD;
	Fri,  9 Sep 2005 09:27:30 +0200 (CEST)
Message-ID: <432139F4.6040302@246tNt.com>
Date:	Fri, 09 Sep 2005 09:29:56 +0200
From:	Sylvain Munaut <tnt@246tNt.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050610)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	ML Linux USB Devel <linux-usb-devel@lists.sourceforge.net>,
	ML Linux MIPS <linux-mips@linux-mips.org>
Subject: Alchemy Au1100 USB Problem
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <tnt@246tNt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8910
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tnt@246tNt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1692
Lines: 53

Hello,


I'm working a a Au1100 System composed of a Cogent CSB650
(http://www.cogcomp.com/csb_csb650.htm) mounted on a custom base board.

This uses a Au1100 to offer two USB host port, one being directly
connected to a on-board smart card controller and the other to a USB
connector so user can plug-in stuff.


Now, I'm running a 2.6 linux-mips.org kernel of a few weeks ago and
using the big-endian mode of the CPU. My problem is with the USB host
controller.

At different times I get URB with condition cone 5 (TIMEOUT) so that
reports error -115 (ETIMEDOUT) to the driver. At first, even at boot the
peripheral plugged in wouldn't be detected at all, but then setting the
Au1100 frequency to 384Mhz (instead of 396Mhz) seemed to help, I haven't
see that issue recently. But when using a usb stick, transfering small
files works at first, but when trying to transfer more data, then it
makes that same -145 error.


Here is an example of what it does :

[4294872.583000] drivers/usb/host/ohci-dbg.c: SUB 811a4080 dev=3
ep=2in-bulk flags=15 len=0/40960 stat=-150

[4294872.597000] au1xxx-ohci au1xxx-ohci.0: urb 811a4080 path 1 ep2in
5ed20000 cc 5 --> status -145

[4294872.597000] au1xxx-ohci au1xxx-ohci.0: urb 811a4080 td a1185140 (3)
cc 5, len=12032/40960

[4294872.597000] drivers/usb/host/ohci-dbg.c: RET 811a4080 dev=3
ep=2in-bulk flags=15 len=12032/40960 stat=-145

[4294872.669000] au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus
[0] = 0x00120103 PRSC PESC PPS PES CCS

[4294872.680000] usb 1-1: reset full speed USB device using au1xxx-ohci
and address 3


Does some one has anyide how I could : workaround, solve, debug, ...
that problem ?



Thanks,

	Sylvain Munaut

From alan@lxorguk.ukuu.org.uk Fri Sep  9 13:22:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 13:22:59 +0100 (BST)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:32183 "EHLO
	lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8225346AbVIIMWo>; Fri, 9 Sep 2005 13:22:44 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.13.4/8.13.4) with ESMTP id j89CsvQ3017226;
	Fri, 9 Sep 2005 13:54:58 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.13.4/8.13.4/Submit) id j89Csr1a017225;
	Fri, 9 Sep 2005 13:54:53 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: scheduling with irqs disabled: init
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	Vadivelan@soc-soft.com
Cc:	linux-mips@linux-mips.org
In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902CD345ED@soc-mail.soc-soft.com>
References: <4BF47D56A0DD2346A1B8D622C5C5902CD345ED@soc-mail.soc-soft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date:	Fri, 09 Sep 2005 13:54:52 +0100
Message-Id: <1126270492.3182.2.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Return-Path: <alan@lxorguk.ukuu.org.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8911
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 400
Lines: 13

On Gwe, 2005-09-09 at 10:25 +0530, Vadivelan@soc-soft.com wrote:
> hi,
> 	I'm porting MVL4.0 kernel on to a mips board. I've been getting
> a call trace as follows.

You should report vendor kernel bugs to the vendor really. I've not seen
an equivalent report for the base kernel and looking at the code the
base kernel appears to correctly drop the lock before calling the wait
for chars level.





From ddaney@avtrex.com Fri Sep  9 16:20:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 16:20:29 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:49159
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8225359AbVIIPUJ>;
	Fri, 9 Sep 2005 16:20:09 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 9 Sep 2005 08:20:03 -0700
Message-ID: <4321A823.8050703@avtrex.com>
Date:	Fri, 09 Sep 2005 08:20:03 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: MIPS SF toolchain
References: <1126098584.12696.19.camel@localhost.localdomain>	 <431F0850.8090804@avtrex.com>	 <1126168866.25388.11.camel@orionlinux.starfleet.com>	 <1126179199.25389.20.camel@orionlinux.starfleet.com>	 <1126182122.25393.27.camel@orionlinux.starfleet.com>	 <432058C1.80106@avtrex.com> <1126248502.20058.5.camel@localhost.localdomain>
In-Reply-To: <1126248502.20058.5.camel@localhost.localdomain>
Content-Type: multipart/mixed;
 boundary="------------050704070601060306050104"
X-OriginalArrivalTime: 09 Sep 2005 15:20:03.0878 (UTC) FILETIME=[F3E50C60:01C5B551]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8912
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 9367
Lines: 162

This is a multi-part message in MIME format.
--------------050704070601060306050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Matej Kupljen wrote:
> Hi
> 
> 
>>>Can I just #ifdef this code if compiled for sf?
>>>
>>
>>I do have some patches for glibc to get rid of these in a soft float 
>>build.  
> 
> 
> Can I see these patches, please?
> (What is the #define for the FP?)
> 
> 
>>However as Ralf Baechle said in the other message, the kernel FP 
>>emulator works and is not that large of an overhead.
> 

Attached is the portions of my patches to glibc-2.3.3 that contain the 
setjump/longjump hacks.  There are other things in there as well, so you 
will have to pick and choose as to which parts you want.

I did this more as a proof of concept rather than the definitive answer. 
  There are still some FP instructions being generated but I have not 
tracked them down yet.

On my 2.4.29 based kernel (mipsel-linux) with glibc 2.3.3 and busybox 
1.00, I don't get the 'Algorithmics/MIPS FPU Emulator v1.5' message 
until I run ldconfig or ftp.  Most other programs don't seem to run any 
FP instructions.

> 
> I also removed the FP Emulator in the kernel, just to be sure that
> no SF ins are executed (I can send the patch to the list, but I know
> there has already been discussion about this).
> 
> IMHO, if we say that we have a SF toolchain then there MUST NOT
> BE any SF ins, otherwise we have a "semi soft float" toolchain.
> Don't you agree?

Of course I agree.

David Daney.

--------------050704070601060306050104
Content-Type: application/x-gzip;
 name="glibc-2.3.3.diff.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="glibc-2.3.3.diff.gz"

H4sICMm/ZkECA2dsaWJjLTIuMy4zLmRpZmYA7Dx7f9rGsn+7n2JC3BoSCSMExiZNTjAmDicY
8zO4TX91j44QC6gRElcPP5rb735ndiUh8cZxTnvvjUMArXZmd+c9sysG5nAIsmtMYWSZfUMu
5lX857jm6DDRcGg49tAc5Sf6J5Y3bVh967sXL17sgmqvWCiosqLgC5SjqlqpFtR8IfoDuXBc
KHwnyzKsR1GSlYJcOIKiWi0VquWjFIoKoniR/oOxfstkYzqVdW8iD1g/GJn20IHX8JbG0Yxb
DW9qusfXUy5LRwUgOD4VulQAv8nfATBb71uIasyMT7LeNwmFaNN4m4Ztb7EfH3DouAYbyIF9
Z9qD5GDihiZuzLpPTZbqhddvv3sJQ9tBHKYv6/iSfXPCe2GrRq2aji+NWgkRvjxf901DRiwj
w0jiw0tN3NTETQ4w2EUkApfB0tZtBQG7foEMhNAJ9heL1dJm9uuGZtqGFQyYpw3YUA8s/3Xm
hs9ZVYqSqhwLdgM8h7Aj/IjE9fxBfvyGmpmNdMoQvZ4RNi/oe752q7ve64Pu+0arBZ1a773W
bXRqV7Xe5RVe1j/Uzhtau3bRiC96tavU9U+Nq27zsh1fd3tXzfZ5fHl6fX7V6Fxe9YDdM0Ob
umxo3kP84YxcfaL5rm57KE8TzdZRMPooUKYLXviJFCRY+jrQfZ3fevCImPzrWHfZgESC8c6O
oVuzK7NPHyE56KtjDRJXpED0OdH5SP3AtAaabpm6B2MHiSO++ro7YtHFWeNdFxr195daXXy0
xUcPWs3TLtyZ/hiFXnwatx7MKxbNgBFq/IocwGE94KqE3MV5Wxbgf+1Od23THnliSuHEjGkQ
frtFVjrRfB0xWTFj6sO/hF34d+zR1z2mTXRjbNqMyEeE9qDZ7vZqrZbWubo8v6pdxNfd+lWz
04svz2q9GrTaWhfqdai/a9XOu9A6E5/1Tkd8QYkyfA07XJ7+s/GxB6fXzdYZXRuu43ma4Uym
poVrIgiof/xI/1OQ2FS7Iuiz64sOXNXaSNDwXnhx0TyHGg0NnZ/PtA5c1D404KJ7/u6ix783
2+8uods4g9p177J+2X6H843ks/tLt9mut67PGl1YaUzgtNZ9H98mg6Yh4cZF+DDf/MkbQ+3n
D9BpXLViOvHxT5tdHC4cllQhgkOzjfLv+MxA4dSQ8fjFvGXxfRMN4dDk1tB19Ye4/Q/NdgbM
Yj5LN1nOlNmJJgHvoiREbacj1wmmSDJOZ03YnwQE8qTvMlSZRBupGtLE+ARJE55efDRTSDue
iTbzSmjY78YOCr7uoszhKtm9waa+6dgeKcr5GTTIMIBn/sGcoWY59kgbOAGqSoo7wrtoQ/6G
Bi0gudVC+Q2vcAUMpTu8umWuh6OQmmnc+Gpjpg+wMcbrhVYhuuYmgyVbEuYlanIdx08YpEUP
CAEqmDWIaDwY4LzuXNPH2RquOfVhZAd4n3+gGWHWEO4NB92WEMDQjsEUZTG07mQehyYSxJkg
uafQdwIbzVYIoNmeh1Sm/jE70DY121y+7eAeyengqknnsYfP3KGORsZCfxAJJ1w1Wo1at0EM
QbVDxeqF3w7QScQeguaALuJAeObn0MThTDSGf6AhcZAL6EFMsnEeeMyH/gM4gs957gAj3xTG
Ht980zff9M03ffNNT+mbFrOIb+7qm7va3V3NZ1zMGDuQ2f8sbOif+0mhy8CbH45Epl0qnUjl
UrmUyLZF07EaeT18DU36fBkh1T1twqr7LSRA+7IK3ASTAUImgbyYLNNw5Qh6P7TtmU1Q+Xw+
7FwX830J5hB8NPG0rHg5C+rzEinzZwbTbvx8Bf6Y2QgJc4NnDWQVG+TmR2CWx3h3Q/fhDZCE
0Yh5A378sXH5juZg+zhj5xV+DRuG8JkY6LsPrw/2P9frsmH8CfuhNd+PzbjcXbZKRLC3twc0
4mwsBel1wKfxGbLsVrdWEP4GW/jAN5lMLiQyhBDhnRwUo3Zd2OTAe73/jxlJFpHu/wOJtx/3
ziQQ35t+4k7uFfyJL7wXU3k1W14/MC9J4DU9bYdqLia+uROkWUyZF1Hz8om7zENNrsL+atQp
SVymHEshkqK3pitSDdeYELklS1suAXxR9ILZOGS0niUxwkqOpTQpTxYKMOyCPLdTHjlDtBBi
6bBOCVeBLmjivK3xpLdpV/hW2k83SK988LnFqRyrJQnfTmYWp3J8pGLT0UlkcRDfEl+KSJe0
CsxzMLGvTcHErUtgeKlPSllJ0esl9VpS6pP2FxuX4E358MQAqfYlcAtePgG7cC8BPx8LINh8
k+i9a9VxeRla3Nih9vhlJegZgkQFUqEa9MYKJBlr+lTUSlHCt8pM/sKmk1IkfwC1uta9Pu32
skmByCU8IXao1+rvGxr+r3/IrvBh0hozJ8GvA9tCVDu5Ghy3d/WLVr+8uKi1z7K/PpnDqXW1
i0a3S6ll6/Jce3f2W+4/Z9j5WF/fxMZcXQTLbWN+lzB9lc2UlkfxEuJB6v86Y2On2WpkURZQ
oSGbyYfwAm8m92prPfWCwwv9E+NB7KobW+hporfQ08KJXCyjilSLJ1X1ZEHNFvR0DkFST8vV
QnGjnlIALg/Y1IOXGIVkDdf3/GA4zAnlLZQkRSlEewWz29XvX+9nnf7v0+F97vu8k6sCvtMb
KkTUjqG+lx8TAxCOJ80s382BPCpgn9BdyXnHwyb0kG9FOUdolRzxL++hCBKEPOw060K/TBtz
ACYPA1uwXoTMt1PdH0MMZ+AYw8CyQn9IaQ9VKMikCBsUriy0QH/PldEaFpQrt/N6txRpnln5
YxdTSm+5bC/tsVnIl4KFXgmFtQiKUi0d42ujtK/ElBT7o2V6s5CuUQkxlHFFUgqVSMbZve/q
MjJ6phAmv8yJC1tcYM+U5lA3erNTzJ76u0qymBfnMK7b9WUyjwTK7lFa8U0JxVdMOtqk/Qsn
vVJIt1jKtpLJqxgrZDJ9bwtpTAOEVvdIVlSyuqXiVnK4iCO9RVvYvEUrcMhx+FBFSp+1Luu1
VkOj+jUmt1nqEwppAfldTsRQvOEoEoCQdcZYdyf6NE+74PLPyBVepZE93+U1WN5EfWSqfvDS
jTcDxsFoMY8DDkeW0eisQIAOPx5IH4jV865rjNxz6I1NqvN8ogoM7cXLZ+3LntZsU53TALw3
1T2PDXg+RTVnjB08BhNnEFjMyyMKOgPhuYYnW2zoE5H3s/pg4KGlN+8hb0iCyBZDmy6HYKQ0
s0Y9uM/Bzbai6vkDE8nkTCaOvVxgl/bYLLZLweKQQUEjWq6q5WqxtFF4V2JKirBSVY83inDI
T59NplSfFIwfzqqhfFXHFemkOBNcuizNie3UM0e2bi3Cxz1upyhD/nBNDyPwmGsOFnvEYsdc
lyqEa2Qu7orz2dCViydGDLLnGbo9lBvtn7Avqi9XXR4WIHnlMGAIpUn39QjqTixoe7ht5Q/9
Plr3w4mJb7qP5t4w/Yf8GLbptIUUroAMBVElK0qyU6iqysYccx2yWBaLVaVSLSmbZJFPvahI
xaOZqNFl7CKfoy7TlpF20ex0tVrv8qJZb/Z+0d5ToqGE5ibebkTe+A9TtCDjNygVs3ZvZIrg
703y6BEIn0gJJLZpmOWgyesHPtM0yGYDG0VzkMs9ioV90/cOPeb/PpmuY2Kq245sTMHGjCwW
QClRElIq7cbIBXRJVmJKUtqOlUXi3YyVeJnYFkZVRnufabNb5s72iFMjvwGxMWU9vKLtC2Rd
fIP2JzGCzGfivWRRY1jBZhIEvEJeu4Hh88T0MxeWYShM3eYFvH49u9Bqp021+Ch2Dyw53Ntc
x+1krx2ZnQQNeV2R1QLZfFWtloubvcc6bILVFZKcwnFV2exBtIGluYFNNlVzmedYt6x6Y++J
P+B/4tRaqaJKpeM4E917DufMJ28Pt7oVMHCGYOl9ZsEBoUS1dH2NPMIBchv8E8juF8u5/I19
Q8AZEJv7HzvZTu9Ka9VykAHsIEEaOOyeH1lO31py7xneI+mYuyW9jYLjqBOz/aWo023Vxel1
G73rjnbewQnO3/wpvnlUyu4rx1IaWS4EIf5FxAv15+9CvOhvGxrGffW/kJbLpHduSL7JpxSl
snISy+oKigmCUZoVTuc5/DOYTMF3OGsIJeZQvvsAUwc9S0T/iXPLBL33lUooYL+71DKTtsEi
hfwMh9aueq0zrdFpti7PrxvZRpvKYp3LZruXEyTJT112azqBx/vnXok9Sr6i2AD/J1f06Hk/
xvwOp4HwXxPdH6PNX2eEF/vuaIoXEcyiqBIUKhRFldTdnO9ynAkPrCpVpbiVB1YqUjERt9Nl
omAPXWfo3+mYkb2jrXudNFWCpm3kJSifQA9TAsx7OpZuMAm6AeaBoKoFCU4dz6eeFzWBplBU
aGdCRadx3a3lAV4crnHGLyF0vM9ENIdyfkFHvd7DDz8k2qjM22p81N4vBgs8FEhTKBkpxIPS
3USskAgVHiNXGj8EQuGHAdt02lGSEpDEboV8eqFMgXj5qFoo7ObT55CVeEW6ROllWdmmrhHD
Q5bZtxK5GE13R6KgrFakUkKo6FJNCBVgDo/A3Frc6Q+ROAC4bIT5GA/2fMIIonyvK1SyD+Vl
aFOUpmm0Cs1D8dSGlqOLgO3wBXQCy4I+nQci7PwWbcRySwSYZlmMyZ5+i/ITDebNxqfhbh0L
QVCqsxkrP4D9YRHl+ftCBqr4LzPJ8PX+Wvgtr2lDNEYjD7/n+PRWwRc3wCscficCl46lsjoj
MB0tKc8IjGQgz0/bJyjxmB3zkHYpQTx39ervuK1fNXVDQ+AVCzd8Q+HA+ypn3ctEAJ6YIE3o
vJNfM/5oumoCo2nukdY/DGXlEWbg6yx/ut+OupoGnln8Cln8Mkbhld0s/iK+ZBBeqJZPtrP2
UjmKV5AHFyFSb8oMc4gJLukHCYfH/itgtsF4ve3fEwNtv38QHubixxrCoA1lh7IhEbjVnekD
0mTsQ7aeA+Xk5Eii94oEONsCf1f4e5G/q+TP37mMrfYxwlrw2iCvr/E6oOtTIMtFp30NdWiZ
fVd3H/Lxlo8Ua8JfvkT+XvoKC13K22OpmLAJdFn+e3jyuCZTv7xu97SzRr2VHbrOZGpIHrPQ
lFDlNa6y3DrmIFVdobqKppHJ51yCbMBNI4QoILwMUS0hz9aYRSVTkU4Ks+emwsnXO1eYO1y1
U8WEZzxKiQOS2mmzrRYpSElXDER7EhuF07Wzs+vo+HlGHwwyJK+2A4Egaapv9/p01tcL+qm+
OAtmzc3jqLR0GkeltbMY4DSCzNrBBzi66MKPJvBar0ql37hqs5lgK+opbVFQ+dpkWl3NeXLq
PMY9iQKWpgf366LIZK8dXVMSNFkHLBSrRfRN5d0c0zy2ZCCJbqmwXRmwIqmJeJEu43gxqrZ6
5mg2FmTpSz8YAo+NKJShoG6ie5/Cq6n4HE7JIHzeJnLs+g5ax+2jxvzKyMnbEDfi3HHq28WQ
3oYYcgmuVfHkdhQUAXxJKsU2cNWcjnaYk7phfcc74Cqtx6XuQvcyx/UsDkuRqRQ2kxR06q9W
MviOIttthkGHJFIXngeVpZIyc8n/96kaG/6vS9svEvVyRTpKntM/lo4qq3lEOdFWusjpcLSS
poRH3RpPJcSzjRkLqYz+Cc3WA4wemQhiEjfEJO77gkjiaI6v3dVsj7PBJaleF4nNxxT7v0BW
mo4EuhSCoy0dJAsAfuDagoHENOJTmP9G9v2RWR9eHCItN1T7kr12dasJ0NCtoi88xvyAV1RK
u5Vn5rElantFZdnZlaUZwQmlAKEVFyU1ITvdX7raVeP8rPFOFM+iAD3Vzo3iIXcAyMOHSd+x
MIaOSzTiiTzKntB1900fMIDifQ9F+nGSSD8eMfaKXbpHzeex8hKgyvjs3t8kMbN+j5CZGfBc
laBUma/hHm8jNWl8SbkpVlV1u3BMlYonKbmJeDFkOiooC5mR4JE42YGtodRAjzZ7iBsjZjMX
tT5iVKTsGzdWZ1uymhagjVKLmg8jRKP5YrtCTDMpYrtMc6WAfe2p7yiNgW3e08WtOBaZ3H03
R+sFdDvQ7WV2O3yx8VNUKJSq6lFV3X6/efshkpJNJxh2t4jpHYZu87xda83vMZBVuq5ftnuN
j731Gw3J+S3da4iFb9nJhGdJGzlDpcWnEVAuPzDXZhZED4P22ZASlmJeyStRQqqHxxcWUUjQ
D0SMAHcMbEZPYc5mvNxs/70ItEJh/2KiPZ02+/oj9JgDPYkGc0yzwKVMx7XLlaq6fT1gG+RJ
rS1v8YCRyEZVSY390aya+KF9eUa/56B1f7oq7e0Vl97c20t0bDXb1x+5iR/Tzzb4Xlwz6zPL
uYurmZE2brLyvGpAgkJnVgeMjsv2efGYonw6K6sb6DbQd5hGvMsUyRqSRCSFfHELx9e+5uJW
a9LXXvBTaMsnrtHarvqSAvtCjUnhenqdWUCf3tkvVLaL4qTkyTrpOLEXQEc0LMoK6cxpyCCK
l4D2B2zHB5QKG3moW2gBmaGTEXeGQNxjLrNDkzjVBwNkfsRnlI0zxn8Qgv94wRD+neD8AY05
4AeNUDrFAgXgy+3E8dkycQwHSNArPLf3FHK2/Fj3NhBfKF0Lx74LRSgW6ImXcunLAqn0MXDx
DBr91iBi3nj0dvZcFP22hG5Z8veofksahfAdxRVdgPCIH8j3YIDchOT5Z4wD6CA+gke/ZIeX
P4J8hvbstA7y4AL+m+8O7QEJkGzDgff2X7Ep1NpX2k3213/Bby9ucpB/sb//NrpHkcmNEnZR
3k4PQjT09waHfFvND17nx7m8ze78V8DPI1FZAuP0KQe+xLB9vh9CHg7Y7aEdWJZ4hDHGyh8B
P3i+7UbMwasYMl7Y4b9usqnp59pHJe3wRjnE2f+4bM6poRd2gdbsRvHhuWXgnIqOfP2v4tTQ
oh9NwQX+P2LZU1g2jGF1sbltwGOAvtC+JTDNmbiiUi1WvszEzSFPes7CsoPPSz1nKa5/cA0p
SWphlhPFzuqBF1zI6sUPCsR3M8InybNKRGbtEwZh2BZ5WINhxuLygwD+WPej6qlY2cxhJ52q
8MliWIIjN87B6GeGdI8SGHLjoQcmcubpyAGOwjMivD0JPP+p5CvMkehnFHYJ0uYhv1zSUuie
vjSxbIS0zKmVx57DVP/q0xuwZRr0NEKD6uTr3k7SEoF8qZhEeFLPN6nVgooi8mWhfAp18hGZ
YrV8/HRPO5Hn6dW62vvFZ5yStdB1fNa008Z5s81P53SfkqmUbOzKVQHzBGwViL6C3qdwJ6sa
laqy3WNsdECrtGp35rqLGf3C/oho3VNmVXY6QUu/QgPTwJ06Ik3zk+fIqI59fnbK9wDp07Et
OnB75tgHPtAT9sIw+I6D9t+gnxrwHTD9uAv3Gb548NZ+QNSY7TvoQVxyTDZHGdgW8zyB58H5
n5UqZOfllwNdBay2QDxQoZWSD+8nwpammeCaGyLoczwD90MuNABfV9ZwuF4AAA==
--------------050704070601060306050104--

From ppopov@embeddedalley.com Fri Sep  9 17:03:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Sep 2005 17:05:22 +0100 (BST)
Received: from smtp101.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.236]:1877
	"HELO smtp101.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225359AbVIIQDn>; Fri, 9 Sep 2005 17:03:43 +0100
Received: (qmail 62020 invoked from network); 9 Sep 2005 16:03:33 -0000
Received: from unknown (HELO ?192.168.1.111?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp101.biz.mail.mud.yahoo.com with SMTP; 9 Sep 2005 16:03:33 -0000
Subject: Re: scheduling with irqs disabled: init
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Vadivelan@soc-soft.com
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902CD345ED@soc-mail.soc-soft.com>
References: <4BF47D56A0DD2346A1B8D622C5C5902CD345ED@soc-mail.soc-soft.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 09 Sep 2005 09:03:39 -0700
Message-Id: <1126281819.4915.77.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8913
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1554
Lines: 42

On Fri, 2005-09-09 at 10:25 +0530, Vadivelan@soc-soft.com wrote:
> hi,
> 	I'm porting MVL4.0 kernel on to a mips board. I've been getting
> a call trace as follows.
> 
> BUG: scheduling with irqs disabled: init/0x00000000/1
> caller is schedule_timeout+0x84/0xe8
> Call Trace:
>  [<8030a0a8>] schedule_timeout+0x84/0xe8
>  [<803090b8>] schedule+0x114/0x160
>  [<803090b0>] schedule+0x10c/0x160
>  [<8030a0a8>] schedule_timeout+0x84/0xe8
>  [<80132610>] process_timeout+0x0/0x8
>  [<80132c0c>] msleep_interruptible+0x4c/0x70
>  [<802300a8>] gs_wait_tx_flushed+0x1fc/0x3b0
>  [<8022fc44>] gs_write+0x25c/0x264
>  [<802310cc>] gs_close+0x260/0x394
>  [<80216364>] tty_fasync+0x8c/0x134
>  [<80216b00>] release_dev+0x6f4/0xa08
>  [<8021dddc>] write_chan+0x420/0x48c
>  [<8012107c>] __wake_up+0x44/0x80
>  [<80120f58>] default_wake_function+0x0/0x28
>  [<8017a734>] get_empty_filp+0x64/0x13c
>  [<80215234>] tty_ldisc_deref+0xcc/0x110
>  [<80215b28>] tty_write+0x2bc/0x454
>  [<80216e24>] tty_release+0x10/0x20
>  [<80179988>] vfs_write+0xac/0x114
>  [<8017aacc>] __fput+0x298/0x2d0
>  [<8018e9b8>] getname+0x28/0xfc
>  [<80178d2c>] filp_close+0x54/0xb4
>  [<80178d24>] filp_close+0x4c/0xb4
>  [<8010bc64>] stack_done+0x20/0x3c
> 
> I'm totally unaware of the bug. Can anyone help me fix it?

Few developers have access to MVL4.0, especially since it just shipped.
Most likely this is a bug in your board port though so unless you get
help directly on MVL4.0, I would suggest you first port linux-mips to
your board and then move your patch to MVL4.0.

Pete


From anemo@mba.ocn.ne.jp Mon Sep 12 03:34:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Sep 2005 03:35:05 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:53026
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225554AbVILCer>; Mon, 12 Sep 2005 03:34:47 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 12 Sep 2005 02:36:20 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 8D49A1F655;
	Mon, 12 Sep 2005 11:36:18 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7A0D41F64A;
	Mon, 12 Sep 2005 11:36:18 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8C2aIoj042837;
	Mon, 12 Sep 2005 11:36:18 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Mon, 12 Sep 2005 11:36:17 +0900 (JST)
Message-Id: <20050912.113617.108740043.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: handler_tlb[lsm] not flushed explicitly
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050715152329Z8226727-3678+3178@linux-mips.org>
References: <20050715152329Z8226727-3678+3178@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
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8914
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 719
Lines: 19

>>>>> On Fri, 15 Jul 2005 16:23:23 +0100, ralf@linux-mips.org said:
ralf> Modified files:
ralf> 	arch/mips/mm   : c-r4k.c c-tx39.c pg-r4k.c tlbex.c 

ralf> Log message:
ralf> 	Avoid SMP cacheflushes.  This is a minor optimization of startup but
ralf> 	will also avoid smp_call_function from doing stupid things when called
ralf> 	from a CPU that is not yet marked online.

This change removed some flush_icache_range() from tlbex.c.  Now the
refill handler is flushed by last flush_icache_range() in trap_init(),
but it seems handle_tlbl[], handle_tlbs[], handle_tlbm[] are not
explicitly flushed to main memory.

We should call __flush_cache_all() instead of flush_icache_range() in
 trap_init() ?

---
Atsushi Nemoto

From matej.kupljen@ultra.si Mon Sep 12 08:34:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Sep 2005 08:34:48 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:8857 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8224894AbVILHe3>; Mon, 12 Sep 2005 08:34:29 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id D55CCC092;
	Mon, 12 Sep 2005 09:34:22 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id 93DDD1BC08A;
	Mon, 12 Sep 2005 09:34:24 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id AA2581A18B4;
	Mon, 12 Sep 2005 09:34:24 +0200 (CEST)
Subject: Re: MIPS SF toolchain
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	David Daney <ddaney@avtrex.com>
Cc:	crossgcc@sources.redhat.com, linux-mips@linux-mips.org
In-Reply-To: <4321A823.8050703@avtrex.com>
References: <1126098584.12696.19.camel@localhost.localdomain>
	 <431F0850.8090804@avtrex.com>
	 <1126168866.25388.11.camel@orionlinux.starfleet.com>
	 <1126179199.25389.20.camel@orionlinux.starfleet.com>
	 <1126182122.25393.27.camel@orionlinux.starfleet.com>
	 <432058C1.80106@avtrex.com>
	 <1126248502.20058.5.camel@localhost.localdomain>
	 <4321A823.8050703@avtrex.com>
Content-Type: multipart/mixed; boundary="=-PxFfBUIefT8W1dpZLbJ+"
Date:	Mon, 12 Sep 2005 09:33:58 +0200
Message-Id: <1126510438.9647.8.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8915
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 2377
Lines: 58


--=-PxFfBUIefT8W1dpZLbJ+
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi

> Attached is the portions of my patches to glibc-2.3.3 that contain the 
> setjump/longjump hacks.  There are other things in there as well, so you 
> will have to pick and choose as to which parts you want.

Done that :-)

> I did this more as a proof of concept rather than the definitive answer. 
>   There are still some FP instructions being generated but I have not 
> tracked them down yet.

I did. They were in the sysdeps/mips/fpu_control.h
I tested it with busybox and MPlayer and found no SF ins in the
binaries. I run those binaries on kernel which has no FPU emulator.

Versions:
BINUTILS: 2.16.1
GCC:      3.4.4
GLIBC:    2.3.5

Let me know the results, if someone is going to use this patch.

BR,
Matej

--=-PxFfBUIefT8W1dpZLbJ+
Content-Disposition: attachment; filename=glibc-2.3.5-mips-sf.patch.bz2
Content-Type: application/x-bzip; name=glibc-2.3.5-mips-sf.patch.bz2
Content-Transfer-Encoding: base64

H4sIAA0PJEMCA61Wa4/aOBT9nl9xxUwlKCRxCOGRaSukdne0WlUaia72w2plmcQJmcmrsQOD9s/v
dcJkgIbHVAWUJ/fc43OPr/1tFQnImfRWgBdLJrgPWQpyxXdPl1v4wtaRj8eUb+GD76vznK1lwZ8N
L0s+ad2VlLlrmiIrC48Lo+D+ikn1zkxi0ysyIULPM4eEODqZmYkICSHTsbGSSdwDlvpakvlREGFq
zPaVSf4If5Z5/MhT+JCoW+Opvp2XsSyYIaJPIDOIUi8ufY58461WMy6kgCArKv4iCyQEcYZUNE3T
dR3COFp6+tCwDccUW+HzXJhJhAdK4ywNH5Pc8GD3QbaWTiY6GQMZu87YJcQgLx/oE3yv9fv9fUy9
4noGeaeAbhEgE5eMXDL5AXM+B92eDMbQx+ME5nOt5sMUTjWuDdsaAO9N9aLgYSQkL1ALCWsWAxMJ
dDvM6vTuNND6N1GQ+jwAShUbqiShlSQq2HwPD2UcY9W9pwq5ehNhmjxTeB6LY851wdZYmZdMosmt
Uq2zGCNijjljw4fbYEgG8I50wMVvJ+lAl6frf8i/BqVBjhACr3uK2qnw4YVwqwpXIo2mSqTRrBEJ
h3PPpfITkvWyVMii9GTrwERxchQbuD3DwaMY2z4AT3pWFXtrV+r3b3iKrsYqvHJTXO4fjNOpw/xU
7jBXac+6WHCJRqOsfG5sjI6ydfwNCViWO5y4jnPgOOs6Fx8gH7nYcUejVhcPKxcPX1yMwmvoQxGF
r2jQVRfLMgAc56AysXJbwsTT7i6vz0He0+C/y35eyKzgb/CyccoH4oKbkTfSvsrZ4oKzW6BeXW6P
qlbgNC5vBx+/Adw+z3P6BqjRWSj7Leo5FdTxpMH6qPmsCvrw+e5UrTZqzl2TK/dedHUmgyn0ndkA
XdwurGoEV9Wsoj8+pYSCsa+GmdQwl42+EyaIUjT2FsKfa3zYtQLsWu9I3bUUv4/F6UI13e+4TAuc
VvWaG4VICNQEhihAOt9LjjPN31uwZFmkdR9Qc19NyCrfoJn5l9pckJcURymLLDZWv3SxbkHeW7Qt
sGyXWK4za21305lyFB4tu3KU3OZcVbBMlSjYdeo+1mSgElVgUhbRspScUuh2sdiZX11SuviD0l5t
BqXwV6b2UdXehnm4yRLRbjewYoW/Ydj0drCwyYqd3OdMdIPPo5QD/f3hL3r/27fPf3e9TU8xEoki
0BjjwBf4l95R7KItVh7EYnQTjM6JBcdTa/6j54u9543hUIwvPGC4EzwYMgg1BXDFkLgJLPOd4fgz
tvn0B9n37u+0/wEGGQxQAwsAAA==


--=-PxFfBUIefT8W1dpZLbJ+--


From ppopov@embeddedalley.com Tue Sep 13 02:30:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 02:30:47 +0100 (BST)
Received: from smtp103.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.238]:41845
	"HELO smtp103.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225319AbVIMBab>; Tue, 13 Sep 2005 02:30:31 +0100
Received: (qmail 12132 invoked from network); 13 Sep 2005 01:30:23 -0000
Received: from unknown (HELO ?192.168.1.111?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp103.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2005 01:30:23 -0000
Subject: deletion of boards
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Mon, 12 Sep 2005 18:30:34 -0700
Message-Id: <1126575034.11755.85.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8916
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 192
Lines: 7


The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
in 2.6 and seem to be of very little interest to anyone. Any objections
if I remove them to reduce the clutter?

Pete


From anemo@mba.ocn.ne.jp Tue Sep 13 02:47:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 02:47:58 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:31267
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225319AbVIMBrl>; Tue, 13 Sep 2005 02:47:41 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 13 Sep 2005 01:49:14 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id CEAAA1F63F
	for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 10:49:11 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id C308A1F63C
	for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 10:49:11 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8D1nBoj047382
	for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 10:49:11 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Tue, 13 Sep 2005 10:49:11 +0900 (JST)
Message-Id: <20050913.104911.75185617.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Subject: potential problem in au1000_generic.c
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8917
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 703
Lines: 35

I found a potential probelm in au1x00_pcmcia_socket_probe().

This function roughly looks like:

int au1x00_pcmcia_socket_probe(struct device *dev, struct pcmcia_low_level *ops, int first, int nr)
{
...
	for (i = 0; i < nr; i++) {
		struct au1000_pcmcia_socket *skt = PCMCIA_SOCKET(i);
...
		ret = pcmcia_register_socket(&skt->socket);
		if (ret)
			goto out_err;
...
	}
...
	return 0;

	do {
		struct au1000_pcmcia_socket *skt = PCMCIA_SOCKET(i);
...
out_err:
...
		ops->hw_shutdown(skt);
		i--;
	} while (i > 0);
...
}

The 'out_err' path seems broken since 'skt' in for-loop and
do-while-loop are another variable.  The local variable 'skt' should
be declared outside those loop.

---
Atsushi Nemoto

From t.sailer@alumni.ethz.ch Tue Sep 13 08:14:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 08:14:29 +0100 (BST)
Received: from mxout.hispeed.ch ([IPv6:::ffff:62.2.95.247]:49562 "EHLO
	smtp.hispeed.ch") by linux-mips.org with ESMTP id <S8224988AbVIMHOJ>;
	Tue, 13 Sep 2005 08:14:09 +0100
Received: from xbox.hb9jnx.ampr.org (84-73-56-159.dclient.hispeed.ch [84.73.56.159])
	(authenticated bits=0)
	by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j8D7E4Cu015829
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL);
	Tue, 13 Sep 2005 09:14:05 +0200
Received: from [192.168.1.5] (48.49.62.81.cust.bluewin.ch [81.62.49.48])
	(authenticated bits=0)
	by xbox.hb9jnx.ampr.org (8.13.4/8.13.4) with ESMTP id j8D7E2q4020976
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Tue, 13 Sep 2005 09:14:03 +0200
Subject: Re: deletion of boards
From:	Thomas Sailer <t.sailer@alumni.ethz.ch>
To:	ppopov@embeddedalley.com
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1126575034.11755.85.camel@localhost.localdomain>
References: <1126575034.11755.85.camel@localhost.localdomain>
Content-Type: text/plain
Organization: e-vision, inc.
Date:	Tue, 13 Sep 2005 09:14:02 +0200
Message-Id: <1126595642.5107.46.camel@playstation2.hb9jnx.ampr.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on smtp-02.tornado.cablecom.ch
X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on xbox.hb9jnx
X-Virus-Status:	Clean
X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics:	smtp-02.tornado.cablecom.ch 32700; Body=2
	Fuz1=2 Fuz2=2
Return-Path: <t.sailer@alumni.ethz.ch>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8918
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: t.sailer@alumni.ethz.ch
Precedence: bulk
X-list: linux-mips
Content-Length: 373
Lines: 11

On Mon, 2005-09-12 at 18:30 -0700, Pete Popov wrote:
> The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
> in 2.6 and seem to be of very little interest to anyone. Any objections
> if I remove them to reduce the clutter?

Yes. The Pb1000 mostly worked for me 3 months ago with 2.6, and I'm
interested in using it sometime in the near future...

Tom



From matej.kupljen@ultra.si Tue Sep 13 08:22:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 08:23:05 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:48554 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8224988AbVIMHWt>; Tue, 13 Sep 2005 08:22:49 +0100
Received: from localhost (in-3.mx.triera.net [213.161.0.27])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id C0855C021;
	Tue, 13 Sep 2005 09:22:43 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-3.mx.triera.net (Postfix) with SMTP id 8CBFF1BC093;
	Tue, 13 Sep 2005 09:22:44 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id D76FB1A18A5;
	Tue, 13 Sep 2005 09:22:44 +0200 (CEST)
Subject: Re: deletion of boards
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	ppopov@embeddedalley.com
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1126575034.11755.85.camel@localhost.localdomain>
References: <1126575034.11755.85.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Tue, 13 Sep 2005 09:22:14 +0200
Message-Id: <1126596134.28382.7.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8919
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 140
Lines: 10

Hi

> The AMD Pb1000, Pb1100, Pb1500, 

I know that in Pb1200 there is some code for DBAU1200,
but don't know for those boards.

BR,
Matej


From ppopov@embeddedalley.com Tue Sep 13 08:26:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 08:26:28 +0100 (BST)
Received: from smtp102.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.237]:54463
	"HELO smtp102.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8224988AbVIMH0L>; Tue, 13 Sep 2005 08:26:11 +0100
Received: (qmail 74769 invoked from network); 13 Sep 2005 07:26:00 -0000
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp102.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2005 07:26:00 -0000
Subject: Re: deletion of boards
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Matej Kupljen <matej.kupljen@ultra.si>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1126596134.28382.7.camel@localhost.localdomain>
References: <1126575034.11755.85.camel@localhost.localdomain>
	 <1126596134.28382.7.camel@localhost.localdomain>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 13 Sep 2005 00:26:10 -0700
Message-Id: <1126596370.11755.97.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8920
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 296
Lines: 13

On Tue, 2005-09-13 at 09:22 +0200, Matej Kupljen wrote:
> Hi
> 
> > The AMD Pb1000, Pb1100, Pb1500, 
> 
> I know that in Pb1200 there is some code for DBAU1200,
> but don't know for those boards.

Pb1200 would stay. Actually, the support isn't in 2.6 yet but I'll be
working on that soon.

Pete


From matej.kupljen@ultra.si Tue Sep 13 08:36:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 08:36:43 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:42668 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225009AbVIMHgL>; Tue, 13 Sep 2005 08:36:11 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 423ECC021;
	Tue, 13 Sep 2005 09:36:06 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id ECDCC1BC07E;
	Tue, 13 Sep 2005 09:36:07 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 27E9C1A18B0;
	Tue, 13 Sep 2005 09:36:08 +0200 (CEST)
Subject: Re: deletion of boards
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	ppopov@embeddedalley.com
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1126596370.11755.97.camel@localhost.localdomain>
References: <1126575034.11755.85.camel@localhost.localdomain>
	 <1126596134.28382.7.camel@localhost.localdomain>
	 <1126596370.11755.97.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Tue, 13 Sep 2005 09:35:37 +0200
Message-Id: <1126596937.28382.11.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8921
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 185
Lines: 13

Hi

> Pb1200 would stay. Actually, the support isn't in 2.6 yet but I'll be
> working on that soon.

Great news!

Do you get any support from AMD?
Any plans to support MAE?

BR,
Matej


From ralf@linux-mips.org Tue Sep 13 13:24:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 13:25:16 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:21011 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225272AbVIMMY4>; Tue, 13 Sep 2005 13:24:56 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8DCOgUh009720;
	Tue, 13 Sep 2005 13:24:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8DCOeX7009719;
	Tue, 13 Sep 2005 13:24:40 +0100
Date:	Tue, 13 Sep 2005 13:24:40 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: deletion of boards
Message-ID: <20050913122440.GA3224@linux-mips.org>
References: <1126575034.11755.85.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1126575034.11755.85.camel@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8922
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 623
Lines: 13

On Mon, Sep 12, 2005 at 06:30:34PM -0700, Pete Popov wrote:

> The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
> in 2.6 and seem to be of very little interest to anyone. Any objections
> if I remove them to reduce the clutter?

The inflation of evaluation boards is generally some sort of problem; in
many cases they are on the market only for a very short time before they're
replaced - we're talking about a time frame of like 6 months or so.  That
means the time that a Linux port is actually of interest if often just
as short.  Which means, we have quite a few candidates for deletion.

  Ralf

From sjhill@realitydiluted.com Tue Sep 13 13:42:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 13:42:17 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:10417 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225223AbVIMMmC>; Tue, 13 Sep 2005 13:42:02 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1EF9Az-0004Si-Q4; Tue, 13 Sep 2005 06:42:13 -0500
Subject: Re: deletion of boards
In-Reply-To: <20050913122440.GA3224@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Date:	Tue, 13 Sep 2005 06:42:13 -0500 (CDT)
CC:	Pete Popov <ppopov@embeddedalley.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1EF9Az-0004Si-Q4@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8923
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 963
Lines: 18

> > The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
> > in 2.6 and seem to be of very little interest to anyone. Any objections
> > if I remove them to reduce the clutter?
> 
> The inflation of evaluation boards is generally some sort of problem; in
> many cases they are on the market only for a very short time before they're
> replaced - we're talking about a time frame of like 6 months or so.  That
> means the time that a Linux port is actually of interest if often just
> as short.  Which means, we have quite a few candidates for deletion.
> 
I would agree with this. Could I make a small suggestion? How about for
boards that are going to be removed, someone at least tries to build a
kernel for it, if it works then tag CVS as such for that board. If not,
blow it away. This allows someone who possibly has an interest later on
to at least be able to pull the last known working snapshot for their
board. Just a thought.

-Steve

From ralf@linux-mips.org Tue Sep 13 13:45:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 13:46:05 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:22047 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225223AbVIMMpu>; Tue, 13 Sep 2005 13:45:50 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8DCjid3010413
	for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 13:45:44 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8DCjiXe010412
	for linux-mips@linux-mips.org; Tue, 13 Sep 2005 13:45:44 +0100
Date:	Tue, 13 Sep 2005 13:45:44 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Git
Message-ID: <20050913124544.GC3224@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8924
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 624
Lines: 21

As a heads up, I've started playing with GIT as the replacement of CVS.
For information on the status of that conversion please see

  http://www.linux-mips.org/wiki/Git

The converted repositories are accessible at via rsync at

  rsync://ftp.linux-mips.org/git

And there gitweb, a web frontend to replace cvsweb available at:

  http://www.linux-mips.org/wiki/git

Browse around, let me know if you find anything that doesn't work as you
want it to.

For those with write permission into CVS, for now continue using CVS
as always.  For now the conversion is still only for testing and
figuring out all the kinks.

  Ralf

From sjhill@realitydiluted.com Tue Sep 13 14:14:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 14:15:05 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:19889 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225223AbVIMNOs>; Tue, 13 Sep 2005 14:14:48 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1EF9gl-0004U5-Rz; Tue, 13 Sep 2005 07:15:03 -0500
Subject: Re: Git
In-Reply-To: <20050913124544.GC3224@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Date:	Tue, 13 Sep 2005 07:15:03 -0500 (CDT)
CC:	linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1EF9gl-0004U5-Rz@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8925
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 294
Lines: 8

> As a heads up, I've started playing with GIT as the replacement of CVS.
> For information on the status of that conversion please see
> 
I assume the reason for choosing GIT was because the main line kernel
uses the same source management tool. No chance of using Subversion I
guess.

-Steve

From ralf@linux-mips.org Tue Sep 13 14:21:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 14:22:16 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:33310 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225223AbVIMNV5>; Tue, 13 Sep 2005 14:21:57 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8DDLpOM011642;
	Tue, 13 Sep 2005 14:21:52 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8DDLpaj011641;
	Tue, 13 Sep 2005 14:21:51 +0100
Date:	Tue, 13 Sep 2005 14:21:50 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	sjhill@realitydiluted.com
Cc:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050913132150.GD3224@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org> <E1EF9gl-0004U5-Rz@real.realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1EF9gl-0004U5-Rz@real.realitydiluted.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8926
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 513
Lines: 15

On Tue, Sep 13, 2005 at 07:15:03AM -0500, sjhill@realitydiluted.com wrote:

> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> > 
> I assume the reason for choosing GIT was because the main line kernel
> uses the same source management tool. No chance of using Subversion I
> guess.

Subversion maybe better but not good enough to justify the pain of
switching, I think.

Btw, can subversion do a checkout in 10s?

  Ralf

From jbglaw@lug-owl.de Tue Sep 13 14:31:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 14:31:48 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:21122 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225458AbVIMNbc>;
	Tue, 13 Sep 2005 14:31:32 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id C968EF004C; Tue, 13 Sep 2005 15:31:26 +0200 (CEST)
Date:	Tue, 13 Sep 2005 15:31:26 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050913133126.GO23161@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="HrsILUyxNtiOryfc"
Content-Disposition: inline
In-Reply-To: <20050913124544.GC3224@linux-mips.org>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8927
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1348
Lines: 43


--HrsILUyxNtiOryfc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-09-13 13:45:44 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> As a heads up, I've started playing with GIT as the replacement of CVS.
> For information on the status of that conversion please see
>=20
>   http://www.linux-mips.org/wiki/Git

Which docs did you use to get yourself started? I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice
if we'd present what we know in Oldenburg (I already offered to do so,
Joey planed it for Saturday).

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--HrsILUyxNtiOryfc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJtSuHb1edYOZ4bsRAubrAJ91uV+z/JyVdebtmpimR7OqFetwhQCfQZYo
abowGeuDVZiSlraT17T77fc=
=OMXn
-----END PGP SIGNATURE-----

--HrsILUyxNtiOryfc--

From jbglaw@lug-owl.de Tue Sep 13 14:34:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 14:34:56 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:23426 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225463AbVIMNek>;
	Tue, 13 Sep 2005 14:34:40 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id DE74AF0033; Tue, 13 Sep 2005 15:34:36 +0200 (CEST)
Date:	Tue, 13 Sep 2005 15:34:36 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	sjhill@realitydiluted.com
Cc:	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050913133436.GP23161@lug-owl.de>
Mail-Followup-To: sjhill@realitydiluted.com,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org> <E1EF9gl-0004U5-Rz@real.realitydiluted.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="CVXKxAdNG2kQIXaJ"
Content-Disposition: inline
In-Reply-To: <E1EF9gl-0004U5-Rz@real.realitydiluted.com>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8928
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1720
Lines: 52


--CVXKxAdNG2kQIXaJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-09-13 07:15:03 -0500, sjhill@realitydiluted.com <sjhill@realit=
ydiluted.com> wrote:
> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> >=20
> I assume the reason for choosing GIT was because the main line kernel
> uses the same source management tool. No chance of using Subversion I
> guess.

Is SVN already distributed? In the past, the non-distributed reality
of CVS is what bought me a lot of trouble. And SVN isn't really
designed for distribution, is it?

I for one see SVN as a CVS rewrite with some design flaws fixed, but
it's for sure not what I actually want to use.

So I'm currently learning to use GIT. It's a bit strange when you
start using it (because usually I interact with git itself as well as
with eg. cogito), but I slowly get used to it :-)

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--CVXKxAdNG2kQIXaJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJtVsHb1edYOZ4bsRAqRAAKCEG3cxPHrtDrD25cmVxh05DB91TACfXtvp
Hbmcbr6/Sk+X52YHBFA3mJE=
=1KcS
-----END PGP SIGNATURE-----

--CVXKxAdNG2kQIXaJ--

From ths@networkno.de Tue Sep 13 15:50:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 15:50:47 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:7324 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8225280AbVIMOuZ>;
	Tue, 13 Sep 2005 15:50:25 +0100
Received: from port-195-158-179-11.dynamic.qsc.de ([195.158.179.11] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1EFC6z-0001ZM-00
	for linux-mips@linux-mips.org; Tue, 13 Sep 2005 16:50:17 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EFC6z-0001GH-C9
	for linux-mips@linux-mips.org; Tue, 13 Sep 2005 16:50:17 +0200
Date:	Tue, 13 Sep 2005 16:50:17 +0200
To:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050913145017.GN32506@hattusa.textio>
References: <20050913124544.GC3224@linux-mips.org> <E1EF9gl-0004U5-Rz@real.realitydiluted.com> <20050913133436.GP23161@lug-owl.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg"
Content-Disposition: inline
In-Reply-To: <20050913133436.GP23161@lug-owl.de>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8929
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1544
Lines: 49


--C1iGAkRnbeBonpVg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Jan-Benedict Glaw wrote:
> On Tue, 2005-09-13 07:15:03 -0500, sjhill@realitydiluted.com <sjhill@real=
itydiluted.com> wrote:
> > > As a heads up, I've started playing with GIT as the replacement of CV=
S.
> > > For information on the status of that conversion please see
> > >=20
> > I assume the reason for choosing GIT was because the main line kernel
> > uses the same source management tool. No chance of using Subversion I
> > guess.
>=20
> Is SVN already distributed? In the past, the non-distributed reality
> of CVS is what bought me a lot of trouble. And SVN isn't really
> designed for distribution, is it?

SVN isn't, but SVK (which uses regular SVN) is.

> I for one see SVN as a CVS rewrite with some design flaws fixed, but
> it's for sure not what I actually want to use.
>=20
> So I'm currently learning to use GIT. It's a bit strange when you
> start using it (because usually I interact with git itself as well as
> with eg. cogito), but I slowly get used to it :-)

I think for kernel development git is the way to go.


Thiemo

--C1iGAkRnbeBonpVg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJuX/XNuq0tFCNaARAt1XAJ9EhPKO23Sv3MOHwfna4Tj5/nEaKACg+ZbM
iJ77MFJ40gMWaecmA4w+zww=
=NpPX
-----END PGP SIGNATURE-----

--C1iGAkRnbeBonpVg--

From ralf@linux-mips.org Tue Sep 13 16:20:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 16:21:02 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:11287 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225280AbVIMPUo>; Tue, 13 Sep 2005 16:20:44 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8DFKca9015228
	for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 16:20:38 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8DFKcek015227
	for linux-mips@linux-mips.org; Tue, 13 Sep 2005 16:20:38 +0100
Date:	Tue, 13 Sep 2005 16:20:38 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050913152038.GE3224@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050913133126.GO23161@lug-owl.de>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8930
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 897
Lines: 25

On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:

> On Tue, 2005-09-13 13:45:44 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> > 
> >   http://www.linux-mips.org/wiki/Git
> 
> Which docs did you use to get yourself started?

The tutorial.txt that comes with git is ok I guess; cvs-migration.txt is
helpful for CVS [1] experienced users.  And of course, my favorite search
engine.

> I'm also on the way
> getting familiar with GIT, doing my very first steps. It would be nice
> if we'd present what we know in Oldenburg (I already offered to do so,
> Joey planed it for Saturday).

Sounds like a plan.  And maybe present some of the other alternatives
to CVS as well?

  Ralf

[1] http://en.wikipedia.org/wiki/Cyclic_Vomiting_Syndrome

From ppopov@embeddedalley.com Tue Sep 13 16:57:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 16:57:52 +0100 (BST)
Received: from smtp102.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.237]:45223
	"HELO smtp102.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225280AbVIMP5e>; Tue, 13 Sep 2005 16:57:34 +0100
Received: (qmail 9569 invoked from network); 13 Sep 2005 15:57:26 -0000
Received: from unknown (HELO ?192.168.1.111?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp102.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2005 15:57:25 -0000
Subject: Re: deletion of boards
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Matej Kupljen <matej.kupljen@ultra.si>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1126596937.28382.11.camel@localhost.localdomain>
References: <1126575034.11755.85.camel@localhost.localdomain>
	 <1126596134.28382.7.camel@localhost.localdomain>
	 <1126596370.11755.97.camel@localhost.localdomain>
	 <1126596937.28382.11.camel@localhost.localdomain>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 13 Sep 2005 08:57:33 -0700
Message-Id: <1126627053.11755.132.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8931
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 321
Lines: 18

On Tue, 2005-09-13 at 09:35 +0200, Matej Kupljen wrote:
> Hi
> 
> > Pb1200 would stay. Actually, the support isn't in 2.6 yet but I'll be
> > working on that soon.
> 
> Great news!
> 
> Do you get any support from AMD?

As always.

> Any plans to support MAE?

Don't know yet; I'll let you know as soon as I know.

Pete


From wd@denx.de Tue Sep 13 19:43:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 19:44:02 +0100 (BST)
Received: from mailout08.sul.t-online.com ([IPv6:::ffff:194.25.134.20]:9145
	"EHLO mailout08.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225478AbVIMSnl>; Tue, 13 Sep 2005 19:43:41 +0100
Received: from fwd33.aul.t-online.de 
	by mailout08.sul.t-online.com with smtp 
	id 1EFFkp-0007kO-03; Tue, 13 Sep 2005 20:43:39 +0200
Received: from denx.de (E3Tl6mZcret5btBk7U3Kj5jtyNrxNyd3AfOQIsbfy6V8GxSH6snt00@[84.150.77.213]) by fwd33.sul.t-online.de
	with esmtp id 1EFFkd-1ms0aO0; Tue, 13 Sep 2005 20:43:27 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id BC8BA42B6A; Tue, 13 Sep 2005 20:43:26 +0200 (MEST)
Received: from atlas.denx.de (localhost.localdomain [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP id 635BE3529BB;
	Tue, 13 Sep 2005 20:43:20 +0200 (MEST)
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc:	linux-mips@linux-mips.org
From:	Wolfgang Denk <wd@denx.de>
Subject: Re: Git 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 13 Sep 2005 15:31:26 +0200."
             <20050913133126.GO23161@lug-owl.de> 
Date:	Tue, 13 Sep 2005 20:43:20 +0200
Message-Id: <20050913184320.635BE3529BB@atlas.denx.de>
X-ID:	E3Tl6mZcret5btBk7U3Kj5jtyNrxNyd3AfOQIsbfy6V8GxSH6snt00@t-dialin.net
X-TOI-MSGID: 9d67f5df-7f7f-4b78-be2d-7c10baeb60cb
Return-Path: <wd@denx.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8932
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 779
Lines: 20

In message <20050913133126.GO23161@lug-owl.de> you wrote:
> 
> Which docs did you use to get yourself started? I'm also on the way
> getting familiar with GIT, doing my very first steps. It would be nice
> if we'd present what we know in Oldenburg (I already offered to do so,
> Joey planed it for Saturday).

I collected a bit of information, like postings from the git  mailing
list I found especially informative, at
http://source.denx.net/en/Documents/GitDocs

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is clear that the individual who persecutes a  man,  his  brother,
because he is not of the same opinion, is a monster.       - Voltaire

From tnt@246tNt.com Tue Sep 13 20:33:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 20:33:25 +0100 (BST)
Received: from outmx026.isp.belgacom.be ([IPv6:::ffff:195.238.2.91]:18351 "EHLO
	outmx026.isp.belgacom.be") by linux-mips.org with ESMTP
	id <S8225721AbVIMTdJ>; Tue, 13 Sep 2005 20:33:09 +0100
Received: from outmx026.isp.belgacom.be (localhost [127.0.0.1])
        by outmx026.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j8DJX7Yr029787
        for <linux-mips@linux-mips.org>; Tue, 13 Sep 2005 21:33:07 +0200
        (envelope-from <tnt@246tNt.com>)
Received: from ayanami.246tNt.com (32-129.245.81.adsl.skynet.be [81.245.129.32])
        by outmx026.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j8DJX6aS029776;
	Tue, 13 Sep 2005 21:33:06 +0200
        (envelope-from <tnt@246tNt.com>)
Received: from [10.0.0.245] (246tNt-laptop.lan.ayanami.246tNt.com [10.0.0.245])
	by ayanami.246tNt.com (Postfix) with ESMTP id A282010EF4E;
	Tue, 13 Sep 2005 21:32:47 +0200 (CEST)
Message-ID: <43272A02.7030603@246tNt.com>
Date:	Tue, 13 Sep 2005 21:35:30 +0200
From:	Sylvain Munaut <tnt@246tNt.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050610)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	ppopov@embeddedalley.com
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: deletion of boards
References: <1126575034.11755.85.camel@localhost.localdomain>
In-Reply-To: <1126575034.11755.85.camel@localhost.localdomain>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <tnt@246tNt.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8933
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tnt@246tNt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 323
Lines: 14

Pete Popov wrote:
> The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
> in 2.6 and seem to be of very little interest to anyone. Any objections
> if I remove them to reduce the clutter?
> 
> Pete
> 
> 

Theses files were of some help when bringing up new board based on thos
processors.


    Sylvain

From ppopov@embeddedalley.com Tue Sep 13 20:51:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Sep 2005 20:51:20 +0100 (BST)
Received: from smtp103.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.238]:19300
	"HELO smtp103.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225525AbVIMTvC>; Tue, 13 Sep 2005 20:51:02 +0100
Received: (qmail 79553 invoked from network); 13 Sep 2005 19:50:55 -0000
Received: from unknown (HELO ?192.168.1.111?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp103.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2005 19:50:54 -0000
Subject: Re: deletion of boards
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Sylvain Munaut <tnt@246tNt.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <43272A02.7030603@246tNt.com>
References: <1126575034.11755.85.camel@localhost.localdomain>
	 <43272A02.7030603@246tNt.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 13 Sep 2005 12:51:04 -0700
Message-Id: <1126641064.11755.166.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8934
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1243
Lines: 30

On Tue, 2005-09-13 at 21:35 +0200, Sylvain Munaut wrote:
> Pete Popov wrote:
> > The AMD Pb1000, Pb1100, Pb1500, and Hydrogen3 boards are not up to date
> > in 2.6 and seem to be of very little interest to anyone. Any objections
> > if I remove them to reduce the clutter?
> > 
> > Pete
> > 
> > 
> 
> Theses files were of some help when bringing up new board based on thos
> processors.

Why not use the Db1x equivalent? If you have an au1000 based board, you
should probably base your port on the db1000 board, not the pb1000
anyway.

I didn't get a clear answer on whether it's ok to remove those boards
but I guess that's normal. The problem with keeping boards around that
very few people are interested in is that no one maintains them, the
code is broken, and quite honestly I think it creates confusion for
developers that have a custom board based on, let's say, the Au1500.
Unless that developer knows that the pb1000 code is broken, how would he
know to base his code on the db1000 instead of the pb1000? If the
support for these boards is broken now, it will only get worst. Anytime
someone makes mods to supported boards, it's bound to break something in
the already unsupported ones and make that code even more unusable.

Pete


From dom@mips.com Wed Sep 14 10:45:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 10:46:10 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:3085 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224974AbVINJpx>;
	Wed, 14 Sep 2005 10:45:53 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EFToL-0002pz-00; Wed, 14 Sep 2005 10:44:13 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EFTpZ-0001tN-00; Wed, 14 Sep 2005 10:45:30 +0100
From:	Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17191.61757.80884.8289@mips.com>
Date:	Wed, 14 Sep 2005 10:45:33 +0100
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: Git
In-Reply-To: <20050913152038.GE3224@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org>
	<20050913133126.GO23161@lug-owl.de>
	<20050913152038.GE3224@linux-mips.org>
X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.811,
	required 4, AWL, BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8935
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 411
Lines: 14


Since I didn't understand it, I did some digging around.  I recorded
what I figured out so far (which may, of course, be deeply wrong) in a
wiki page

  http://www.linux-mips.org/wiki/WhatIsGit

Unless and until someone else comes up with a link to something better
like this - which I appreciate quite likely exists somewhere - perhaps
this will get amended by others and become useful.

--
Dominic Sweetman


From jbglaw@lug-owl.de Wed Sep 14 10:59:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 10:59:17 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:8621 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8224974AbVINJ7A>;
	Wed, 14 Sep 2005 10:59:00 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 7D5BFF0070; Wed, 14 Sep 2005 11:58:58 +0200 (CEST)
Date:	Wed, 14 Sep 2005 11:58:58 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050914095858.GD23161@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="3MRlEjvj2/M31Nfs"
Content-Disposition: inline
In-Reply-To: <20050913152038.GE3224@linux-mips.org>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8936
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 3064
Lines: 88


--3MRlEjvj2/M31Nfs
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > I'm also on the way
> > getting familiar with GIT, doing my very first steps. It would be nice
> > if we'd present what we know in Oldenburg (I already offered to do so,
> > Joey planed it for Saturday).
>=20
> Sounds like a plan.  And maybe present some of the other alternatives
> to CVS as well?

I'm not sure if it's worth it. Linus decided against all other SCMs. I
did use (for small test projects) monotone, darcs and arch. (I think
all other alternatives aren't.)

monotone
	Is quite nice'n'easy to use for CVS users, you'll have quite a
	fast start. The network sync protocol can be a bit lengthy at
	a time, but it works. It's acceptable in speed, but not
	exactly "fast". Written in C, code can easily be read and
	hacked.

darcs
	Is easy to use, too, and quite some helpful. Network
	operations are a bit slower than those of monotone, but the
	real point is that it's merging algorithms are awfully slow.
	Also, it's written in Haskell (and getting a working compiler
	isn't exactly trivial), so the code is hard to read (for a C
	person), mostly because Haskell's concept are so different
	(it's a function programming language, after all.)

arch
	Arch can do almost everything; it's network sync protocol is
	quite fast (can use several transports and will make use of
	caches). However, it's not exactly easy to use because of it's
	thousands of commands and it's project name conventions are,
	um, ugly. It has very good merging capabilities, but it's
	heavy use of local caches forces you to have loads of free HDD
	space.

CVS
	Um, we all know the problems, don't we?

SVN
	Not distributed, easy to use.  Though there's a different
	frontend with distribution capabilities. Personally, SVN feels
	like CVS with it's major conceptual problems fixed.

More SCM questions?

So my famous last words are:  I don't think it's worth really
presenting all the other alternatives (except probably reading down
the above text).

To get fixes/port updates/subsystem updates upstream to Linus, GIT is
the way[tm] to go, so we'd try to get familiar with it.

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--3MRlEjvj2/M31Nfs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJ/RiHb1edYOZ4bsRAphJAJ4kg6Zmku1DbRaBICtFmqCBMvLEugCfdeHi
/EhSSaMF0g6ThNwdCaOUieQ=
=EHvR
-----END PGP SIGNATURE-----

--3MRlEjvj2/M31Nfs--

From anemo@mba.ocn.ne.jp Wed Sep 14 11:32:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 11:32:24 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:13331
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8224974AbVINKcH>; Wed, 14 Sep 2005 11:32:07 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 14 Sep 2005 10:33:39 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id AC60E1F67D;
	Wed, 14 Sep 2005 19:33:36 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 976831F66F;
	Wed, 14 Sep 2005 19:33:36 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8EAXaoj053574;
	Wed, 14 Sep 2005 19:33:36 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Wed, 14 Sep 2005 19:33:36 +0900 (JST)
Message-Id: <20050914.193336.108120347.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: module.h build fix
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8937
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 429
Lines: 14

Please insert "B".

diff -u linux-mips/include/asm-mips/module.h linux/include/asm-mips/module.h 
--- linux-mips/include/asm-mips/module.h	2005-09-14 10:14:31.000000000 +0900
+++ linux/include/asm-mips/module.h	2005-09-14 19:29:49.000000000 +0900
@@ -119,7 +119,7 @@
 
 #ifdef CONFIG_32BIT
 #define MODULE_KERNEL_TYPE "32BIT "
-#elif defined CONFIG_64IT
+#elif defined CONFIG_64BIT
 #define MODULE_KERNEL_TYPE "64BIT "
 #endif
 

From ralf@linux-mips.org Wed Sep 14 11:36:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 11:36:20 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:60179 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8224978AbVINKgD>; Wed, 14 Sep 2005 11:36:03 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8EAZv8a018691;
	Wed, 14 Sep 2005 11:35:57 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8EAZu0u018680;
	Wed, 14 Sep 2005 11:35:56 +0100
Date:	Wed, 14 Sep 2005 11:35:56 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: module.h build fix
Message-ID: <20050914103556.GJ3224@linux-mips.org>
References: <20050914.193336.108120347.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050914.193336.108120347.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8938
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 111
Lines: 7

On Wed, Sep 14, 2005 at 07:33:36PM +0900, Atsushi Nemoto wrote:

> Please insert "B".

Whops.  Thanks!

  Ralf

From geert@linux-m68k.org Wed Sep 14 12:23:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 12:23:51 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:50155 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224989AbVINLXf>;
	Wed, 14 Sep 2005 12:23:35 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j8EBNXva001772;
	Wed, 14 Sep 2005 13:23:33 +0200 (MEST)
Date:	Wed, 14 Sep 2005 13:23:22 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Git
In-Reply-To: <20050914095858.GD23161@lug-owl.de>
Message-ID: <Pine.LNX.4.62.0509141322540.1923@numbat.sonytel.be>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de>
 <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8939
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1194
Lines: 32

On Wed, 14 Sep 2005, Jan-Benedict Glaw wrote:
> On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > > I'm also on the way
> > > getting familiar with GIT, doing my very first steps. It would be nice
> > > if we'd present what we know in Oldenburg (I already offered to do so,
> > > Joey planed it for Saturday).
> > 
> > Sounds like a plan.  And maybe present some of the other alternatives
> > to CVS as well?
> 
> I'm not sure if it's worth it. Linus decided against all other SCMs. I
> did use (for small test projects) monotone, darcs and arch. (I think
> all other alternatives aren't.)

Have you tried mercurial?

> To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> the way[tm] to go, so we'd try to get familiar with it.

Still using plain patches and email...

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 jbglaw@lug-owl.de Wed Sep 14 12:46:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 12:47:09 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:2516 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8224978AbVINLqv>;
	Wed, 14 Sep 2005 12:46:51 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 61150F0070; Wed, 14 Sep 2005 13:46:50 +0200 (CEST)
Date:	Wed, 14 Sep 2005 13:46:50 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	Geert Uytterhoeven <geert@linux-m68k.org>
Cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Git
Message-ID: <20050914114650.GF23161@lug-owl.de>
Mail-Followup-To: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de> <Pine.LNX.4.62.0509141322540.1923@numbat.sonytel.be>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="r6fxLKBTHCmC166Z"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.62.0509141322540.1923@numbat.sonytel.be>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8940
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2293
Lines: 69


--r6fxLKBTHCmC166Z
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-09-14 13:23:22 +0200, Geert Uytterhoeven <geert@linux-m68k.org=
> wrote:
> On Wed, 14 Sep 2005, Jan-Benedict Glaw wrote:
> > On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> w=
rote:
> > > On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > > > I'm also on the way
> > > > getting familiar with GIT, doing my very first steps. It would be n=
ice
> > > > if we'd present what we know in Oldenburg (I already offered to do =
so,
> > > > Joey planed it for Saturday).
> > >=20
> > > Sounds like a plan.  And maybe present some of the other alternatives
> > > to CVS as well?
> >=20
> > I'm not sure if it's worth it. Linus decided against all other SCMs. I
> > did use (for small test projects) monotone, darcs and arch. (I think
> > all other alternatives aren't.)
>=20
> Have you tried mercurial?

Nope. I've only used it's web frontend on http://www.kernel.org/hg/ .

Mercurial's author claims that it scales even better than git, esp. on
its network transfer. However, I'm not aware how it scales there right
now, since git got its "packs" implemented.

> > To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> > the way[tm] to go, so we'd try to get familiar with it.
>=20
> Still using plain patches and email...

=2E..which is a nice and actually working scheme, too. At least, it
doesn't require to learn working with a new SCM :-P  Though I think
it's a good idea.

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--r6fxLKBTHCmC166Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKA2qHb1edYOZ4bsRAsv6AJ42sSLsP/2n9JA8FZZGU3AQp+vqrACfYe4H
YJZ9W8LyyJoBACge88TLmP8=
=P9RP
-----END PGP SIGNATURE-----

--r6fxLKBTHCmC166Z--

From ralf@linux-mips.org Wed Sep 14 13:37:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 13:38:13 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:4637 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225007AbVINMh4>; Wed, 14 Sep 2005 13:37:56 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8ECboTI022364
	for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 13:37:50 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8ECboIh022363
	for linux-mips@linux-mips.org; Wed, 14 Sep 2005 13:37:50 +0100
Date:	Wed, 14 Sep 2005 13:37:50 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050914123750.GL3224@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050914095858.GD23161@lug-owl.de>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8941
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2461
Lines: 58

On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote:

> To:	linux-mips@linux-mips.org

If you actually expect finite time answer, don't delete the cc list ...

> monotone
> 	Is quite nice'n'easy to use for CVS users, you'll have quite a
> 	fast start. The network sync protocol can be a bit lengthy at
> 	a time, but it works. It's acceptable in speed, but not
> 	exactly "fast". Written in C, code can easily be read and
> 	hacked.

Git has taken some ideas from Monotone.

> darcs
> 	Is easy to use, too, and quite some helpful. Network
> 	operations are a bit slower than those of monotone, but the
> 	real point is that it's merging algorithms are awfully slow.
> 	Also, it's written in Haskell (and getting a working compiler
> 	isn't exactly trivial), so the code is hard to read (for a C
> 	person), mostly because Haskell's concept are so different
> 	(it's a function programming language, after all.)

In my tests at the beginning of the year darcs's performance was
undescribably low.  The speedup factor needed to make it useful for any
large project probably cannot be described in a floating point number.

> arch
> 	Arch can do almost everything; it's network sync protocol is
> 	quite fast (can use several transports and will make use of
> 	caches). However, it's not exactly easy to use because of it's
> 	thousands of commands and it's project name conventions are,
> 	um, ugly. It has very good merging capabilities, but it's
> 	heavy use of local caches forces you to have loads of free HDD
> 	space.

Git is a huge diskspace consumer also unless repositories are converted.
For example, the Linux kernel repository from CVS did inflate itself to
over 4GB and over 340,000 files.  After packing I got that down to like
170MB.  Not bad compared to the some 770MB of RCS files it's using
currently and < 11s checkout from git can't be wrong either ;-)

> SVN
> 	Not distributed, easy to use.  Though there's a different
> 	frontend with distribution capabilities. Personally, SVN feels
> 	like CVS with it's major conceptual problems fixed.

And plenty of reports about database corruption that are not terribly old
so I'd feel uneasy to keep the crown jewels there.

> To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> the way[tm] to go, so we'd try to get familiar with it.

The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.

  Ralf

From vbarinov@ru.mvista.com Wed Sep 14 13:55:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 13:55:48 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.6] ([IPv6:::ffff:85.21.88.6]:788 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225201AbVINMzd>; Wed, 14 Sep 2005 13:55:33 +0100
Received: from [192.168.12.17] ([10.149.0.1])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j8ECtVt21738;
	Wed, 14 Sep 2005 17:55:31 +0500
Message-ID: <43281DC3.8010602@ru.mvista.com>
Date:	Wed, 14 Sep 2005 16:55:31 +0400
From:	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] Ethernet for TX4927(37) platform
References: <20050913124544.GC3224@linux-mips.org>	<20050913133126.GO23161@lug-owl.de>	<20050913152038.GE3224@linux-mips.org> <17191.61757.80884.8289@mips.com>
In-Reply-To: <17191.61757.80884.8289@mips.com>
Content-Type: multipart/mixed;
 boundary="------------090403010504010608020707"
Return-Path: <vbarinov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8942
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbarinov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1662
Lines: 53

This is a multi-part message in MIME format.
--------------090403010504010608020707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello All!

This as a patch to add ethernet support for TX4927 platform.
Does it makes sence to push it in?

Regards,
Vladimir


--------------090403010504010608020707
Content-Type: text/plain;
 name="pro_mips_tx4927_ethernet.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pro_mips_tx4927_ethernet.patch"

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
        Ethernet support for TX4927/37 platform in 2.6.
                                                                                                                                                             
Index: linux-2.6.10/drivers/net/ne.c
===================================================================
--- linux-2.6.10.orig/drivers/net/ne.c
+++ linux-2.6.10/drivers/net/ne.c
@@ -54,7 +54,9 @@ static const char version2[] =
 #include <asm/system.h>
 #include <asm/io.h>
 
-#if defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938)
+#if defined(CONFIG_TOSHIBA_RBTX4927)
+#include <asm/tx4927/toshiba_rbtx4927.h>
+#elif defined(CONFIG_TOSHIBA_RBTX4938)
 #include <asm/tx4938/rbtx4938.h>
 #endif
 
@@ -237,6 +239,10 @@ struct net_device * __init ne_probe(int 
 	dev->base_addr = 0x07f20280;
 	dev->irq = RBTX4938_RTL_8019_IRQ;
 #endif
+#ifdef CONFIG_TOSHIBA_RBTX4927
+	dev->base_addr = RBTX4927_RTL_8019_BASE;
+	dev->irq = RBTX4927_RTL_8019_IRQ;
+#endif
 	err = do_ne_probe(dev);
 	if (err)
 		goto out;

--------------090403010504010608020707--

From ths@networkno.de Wed Sep 14 14:02:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 14:02:44 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:48612 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8225201AbVINNC0>;
	Wed, 14 Sep 2005 14:02:26 +0100
Received: from port-195-158-179-11.dynamic.qsc.de ([195.158.179.11] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1EFWu3-00045x-00; Wed, 14 Sep 2005 15:02:19 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EFWtj-0001ug-8x; Wed, 14 Sep 2005 15:01:59 +0200
Date:	Wed, 14 Sep 2005 15:01:54 +0200
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050914130154.GQ32506@hattusa.textio>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de> <20050914123750.GL3224@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050914123750.GL3224@linux-mips.org>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8943
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 753
Lines: 22

Ralf Baechle wrote:
[snip]
> > SVN
> > 	Not distributed, easy to use.  Though there's a different
> > 	frontend with distribution capabilities. Personally, SVN feels
> > 	like CVS with it's major conceptual problems fixed.
> 
> And plenty of reports about database corruption that are not terribly old
> so I'd feel uneasy to keep the crown jewels there.

This was related to the underlying berkeleydb, the switch to fsfs
fixed that. (SVN is used for several larger Debian projects like
its Xfree86/XOrg tree, it holds up quite well there.)

Btw, there's also SVK which implements a distributed system on top
of SVN. Some general comparision of the various SCMs:

http://linuxmafia.com/faq/Apps/scm.html
http://www.dwheeler.com/essays/scm.html


Thiemo

From vbarinov@ru.mvista.com Wed Sep 14 14:03:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 14:03:29 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.6] ([IPv6:::ffff:85.21.88.6]:2836 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225204AbVINNCj>; Wed, 14 Sep 2005 14:02:39 +0100
Received: from [192.168.12.17] ([10.149.0.1])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j8ED2ct21785;
	Wed, 14 Sep 2005 18:02:38 +0500
Message-ID: <43281F6E.3010807@ru.mvista.com>
Date:	Wed, 14 Sep 2005 17:02:38 +0400
From:	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] RTC for TX4927(37) platform
References: <20050913124544.GC3224@linux-mips.org>	<20050913133126.GO23161@lug-owl.de>	<20050913152038.GE3224@linux-mips.org> <17191.61757.80884.8289@mips.com> <43281DC3.8010602@ru.mvista.com>
In-Reply-To: <43281DC3.8010602@ru.mvista.com>
Content-Type: multipart/mixed;
 boundary="------------050908050609050203010502"
Return-Path: <vbarinov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8944
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbarinov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 11086
Lines: 355

This is a multi-part message in MIME format.
--------------050908050609050203010502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello All!

This as a patch to add RTC support for TX4927 platform.
The current RTC_DS1742=y can't be ever compiled.

Does it makes sence to push it in?

Regards,
Vladimir

--------------050908050609050203010502
Content-Type: text/plain;
 name="pro_mips_tx4927_rtc.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pro_mips_tx4927_rtc.patch"

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
 	RTC support for TX4927/37 platform in 2.6.
 	
Index: linux-2.6.10/arch/mips/tx4927/common/Makefile
===================================================================
--- linux-2.6.10/arch/mips/tx4927/common/Makefile
+++ linux-2.6.10/arch/mips/tx4927/common/Makefile
@@ -6,7 +6,7 @@
 # unless it's something special (ie not a .c file).
 #
 
-obj-y	+= tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o
+obj-y	+= tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o rtc_ds1742.o
 
 obj-$(CONFIG_TOSHIBA_FPCIB0)	   += smsc_fdc37m81x.o
 obj-$(CONFIG_KGDB)                 += tx4927_dbgio.o
Index: linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
===================================================================
--- linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
+++ linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
@@ -49,6 +49,7 @@
 #define RBTX4927_SW_RESET_ENABLE     0xbc00f002
 #define RBTX4927_SW_RESET_ENABLE_SET            0x01
 
+#define RBTX4927_RTC_BASE	0xbc010000
 
 #define RBTX4927_RTL_8019_BASE (0x1c020280-TBTX4927_ISA_IO_OFFSET)
 #define RBTX4927_RTL_8019_IRQ  (29)
Index: linux-2.6.10/arch/mips/tx4927/common/rtc_ds1742.c
===================================================================
--- /dev/null
+++ linux-2.6.10/arch/mips/tx4927/common/rtc_ds1742.c
@@ -0,0 +1,141 @@
+/*
+ * arch/mips/tx4927/common/rtc_ds1742.c 
+ * 
+ * This is a copy of:  arch/mips/jmr3927/common/rtc_ds1742.c
+ *
+ * Copyright (c) 2001-2005 MontaVista Software Inc.
+ * Copyright (c) 2000-2001 Toshiba Corporation 
+ *
+ * 2001-2005 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is
+ * licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/types.h>
+#include <linux/ds1742rtc.h>
+
+#include <asm/time.h>
+#include <asm/delay.h>
+#include <asm/debug.h>
+
+#define	EPOCH		2000
+
+#undef BCD_TO_BIN
+#define BCD_TO_BIN(val) (((val)&15) + ((val)>>4)*10)
+
+#undef BIN_TO_BCD
+#define BIN_TO_BCD(val) ((((val)/10)<<4) + (val)%10)
+
+unsigned long rtc_base;
+
+/* RTC-dependent code for time.c */
+
+static unsigned long rtc_ds1742_get_time(void)
+{
+	unsigned int year, month, day, hour, minute, second;
+	unsigned int century;
+	static unsigned int save = 0;
+
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	second 	= BCD_TO_BIN(CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	minute 	= BCD_TO_BIN(CMOS_READ(RTC_MINUTES));
+	hour 	= BCD_TO_BIN(CMOS_READ(RTC_HOURS));
+	day 	= BCD_TO_BIN(CMOS_READ(RTC_DATE));
+	month 	= BCD_TO_BIN(CMOS_READ(RTC_MONTH));
+	year 	= BCD_TO_BIN(CMOS_READ(RTC_YEAR));
+	century = BCD_TO_BIN(CMOS_READ(RTC_CENTURY) & RTC_CENTURY_MASK);
+	CMOS_WRITE(0, RTC_CONTROL);
+
+	/* manual -- must wait 500us min between RTC_READ clr and next set */
+	if (save != second)
+		save = second;
+	else
+		udelay(500);
+
+	year += EPOCH;
+
+	return mktime(year, month, day, hour, minute, second);
+}
+
+static int rtc_ds1742_set_time(unsigned long t)
+{
+	struct rtc_time tm;
+	u8 year, month, day, hour, minute, second;
+	u8 cmos_year, cmos_month, cmos_day, cmos_hour, cmos_minute, cmos_second;
+	int cmos_century;
+
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	cmos_second  = (u8) (CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	cmos_minute  = (u8) CMOS_READ(RTC_MINUTES);
+	cmos_hour    = (u8) CMOS_READ(RTC_HOURS);
+	cmos_day     = (u8) CMOS_READ(RTC_DATE);
+	cmos_month   = (u8) CMOS_READ(RTC_MONTH);
+	cmos_year    = (u8) CMOS_READ(RTC_YEAR);
+	cmos_century = CMOS_READ(RTC_CENTURY) & RTC_CENTURY_MASK;
+	CMOS_WRITE(RTC_WRITE, RTC_CONTROL);
+
+	/* convert */
+	to_tm(t, &tm);
+
+	/* check each field one by one */
+	year = BIN_TO_BCD(tm.tm_year - EPOCH);
+	if (year != cmos_year)
+		CMOS_WRITE(year, RTC_YEAR);
+
+	month = BIN_TO_BCD(tm.tm_mon + 1);
+	if (month != (cmos_month & 0x1f))
+		CMOS_WRITE((month & 0x1f) | (cmos_month & ~0x1f), RTC_MONTH);
+
+	day = BIN_TO_BCD(tm.tm_mday);
+	if (day != cmos_day)
+		CMOS_WRITE(day, RTC_DATE);
+
+	if (cmos_hour & 0x40) {
+		/* 12 hour format */
+		hour = 0x40;
+		if (tm.tm_hour > 12) {
+			hour |= 0x20 | (BIN_TO_BCD(hour - 12) & 0x1f);
+		} else {
+			hour |= BIN_TO_BCD(tm.tm_hour);
+		}
+	} else {
+		/* 24 hour format */
+		hour = BIN_TO_BCD(tm.tm_hour) & 0x3f;
+	}
+
+	if (hour != cmos_hour)
+		CMOS_WRITE(hour, RTC_HOURS);
+
+	minute = BIN_TO_BCD(tm.tm_min);
+	if (minute != cmos_minute)
+		CMOS_WRITE(minute, RTC_MINUTES);
+
+	second = BIN_TO_BCD(tm.tm_sec);
+	if (second != cmos_second)
+		CMOS_WRITE(second & RTC_SECONDS_MASK, RTC_SECONDS);
+
+	/* RTC_CENTURY and RTC_CONTROL share same address... */
+	CMOS_WRITE(cmos_century, RTC_CONTROL);
+	return 0;
+}
+
+void rtc_ds1742_init(unsigned long base)
+{
+	u8 cmos_second;
+
+	/* remember the base */
+	rtc_base = base;
+	db_assert((rtc_base & 0xe0000000) == KSEG1);
+
+	/* clear oscillator stop bit */
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	cmos_second = (u8) (CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	CMOS_WRITE(RTC_WRITE, RTC_CONTROL);
+	CMOS_WRITE(cmos_second, RTC_SECONDS);	/* clear msb */
+	CMOS_WRITE(0, RTC_CONTROL);
+
+	/* set the function pointers */
+	rtc_get_time = rtc_ds1742_get_time;
+	rtc_set_time = rtc_ds1742_set_time;
+}
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
@@ -133,9 +133,6 @@ JP7 is not bus master -- do NOT use -- o
 #include <asm/time.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
-#ifdef CONFIG_RTC_DS1742
-#include <linux/ds1742rtc.h>
-#endif
 #ifdef CONFIG_TOSHIBA_FPCIB0
 #include <asm/tx4927/smsc_fdc37m81x.h>
 #endif
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -63,9 +63,7 @@
 #include <asm/time.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
-#ifdef CONFIG_RTC_DS1742
 #include <linux/ds1742rtc.h>
-#endif
 #ifdef CONFIG_TOSHIBA_FPCIB0
 #include <asm/tx4927/smsc_fdc37m81x.h>
 #endif
@@ -970,12 +968,6 @@ void __init toshiba_rbtx4927_setup(void)
 			       "+\n");
 }
 
-#ifdef CONFIG_RTC_DS1742
-extern unsigned long rtc_ds1742_get_time(void);
-extern int rtc_ds1742_set_time(unsigned long);
-extern void rtc_ds1742_wait(void);
-#endif
-
 void __init
 toshiba_rbtx4927_time_init(void)
 {
@@ -984,58 +976,14 @@ toshiba_rbtx4927_time_init(void)
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "-\n");
 
-#ifdef CONFIG_RTC_DS1742
-
-	rtc_get_time = rtc_ds1742_get_time;
-	rtc_set_time = rtc_ds1742_set_time;
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":rtc_ds1742_init()-\n");
-	rtc_ds1742_init(0xbc010000);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":rtc_ds1742_init()+\n");
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_hpt_frequency-\n");
-	rtc_ds1742_wait();
-
-	/* get the count */
-	c1 = read_c0_count();
-
-	/* wait for the seconds to change again */
-	rtc_ds1742_wait();
-
-	/* get the count again */
-	c2 = read_c0_count();
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_hpt_frequency+\n");
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":c1=%12u\n", c1);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":c2=%12u\n", c2);
-
-	/* this diff is as close as we are going to get to counter ticks per sec */
-	mips_hpt_frequency = abs(c2 - c1);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f1=%12u\n", mips_hpt_frequency);
-
-	/* round to 1/10th of a MHz */
-	mips_hpt_frequency /= (100 * 1000);
-	mips_hpt_frequency *= (100 * 1000);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f2=%12u\n", mips_hpt_frequency);
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_INFO,
-				       ":mips_hpt_frequency=%uHz (%uMHz)\n",
-				       mips_hpt_frequency,
-				       mips_hpt_frequency / 1000000);
-#else
-	mips_hpt_frequency = 100000000;
+	rtc_ds1742_init(RBTX4927_RTC_BASE);
+	/*
+	 * Default TX4927 processor speed is 200 MHz. However, it
+	 * can be configured by the user
+	 */
+	mips_hpt_frequency = (CONFIG_TOSHIBA_TX4927_CPU_SPEED * 1000000) / 2;
-#endif
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "+\n");
-
 }
 
 void __init toshiba_rbtx4927_timer_setup(struct irqaction *irq)
Index: linux-2.6.10/include/asm-mips/ds1742.h
===================================================================
--- /dev/null
+++ linux-2.6.10/include/asm-mips/ds1742.h
@@ -0,0 +1,29 @@
+/*
+ * Machine dependent access functions for RTC registers.
+ *
+ * Do not include this file directly. It's included from linux/ds1742rtc.h
+ *
+ * Author: Vladimir Barinov <vbarinov@ru.mvista.com>
+ *
+ * (c) 2005 MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is
+ * licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __LINUX_DS1742_H
+#define __LINUX_DS1742_H
+
+extern unsigned long rtc_base;
+
+static inline unsigned char CMOS_READ(unsigned long addr)
+{
+	return (*(volatile u8 *)(rtc_base + addr));
+}
+
+static inline void CMOS_WRITE(unsigned char data, unsigned long addr)
+{
+	*(volatile u8 *)(rtc_base + addr) = data;
+}
+
+#endif /* __LINUX_DS1742_H */
Index: linux-2.6.10/arch/mips/tx4927/Kconfig
===================================================================
--- linux-2.6.10/arch/mips/tx4927/Kconfig	2005-01-30 23:45:36.000000000 +0300
+++ linux-2.6.10/arch/mips/tx4927/Kconfig	2005-09-14 15:41:00.000000000 +0400
@@ -1,3 +1,11 @@
+config TOSHIBA_TX4927_CPU_SPEED
+        int "CPU speed of the TX4927 processor (MHz)"
+        depends on TOSHIBA_RBTX4927
+        default 200
+        help
+          This sets the speed for the TX4927 processor. The default speed
+          is 200 MHz.
+
 config TOSHIBA_FPCIB0
 	bool "FPCIB0 Backplane Support"
 	depends on TOSHIBA_RBTX4927

--------------050908050609050203010502--

From vbarinov@ru.mvista.com Wed Sep 14 14:04:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 14:04:59 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.6] ([IPv6:::ffff:85.21.88.6]:3092 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225204AbVINNEk>; Wed, 14 Sep 2005 14:04:40 +0100
Received: from [192.168.12.17] ([10.149.0.1])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j8ED4ct21813;
	Wed, 14 Sep 2005 18:04:38 +0500
Message-ID: <43281FE6.4070102@ru.mvista.com>
Date:	Wed, 14 Sep 2005 17:04:38 +0400
From:	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH] Remove compile warnings for TX4927(37) platform
References: <20050913124544.GC3224@linux-mips.org>	<20050913133126.GO23161@lug-owl.de>	<20050913152038.GE3224@linux-mips.org> <17191.61757.80884.8289@mips.com> <43281DC3.8010602@ru.mvista.com> <43281F6E.3010807@ru.mvista.com>
In-Reply-To: <43281F6E.3010807@ru.mvista.com>
Content-Type: multipart/mixed;
 boundary="------------060407040209010203080500"
Return-Path: <vbarinov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8945
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbarinov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3853
Lines: 113

This is a multi-part message in MIME format.
--------------060407040209010203080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello All!

This as a patch to aviod compile warnings for TX4927 platform.

Does it makes sence to push it in?

Regards,
Vladimir


--------------060407040209010203080500
Content-Type: text/plain;
 name="pro_mips_tx4927_warnings.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pro_mips_tx4927_warnings.patch"

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
 	Patch to aviod compile warnings from TX4927/37 platform.
                                                                                                                                                             
Index: linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
@@ -567,6 +567,8 @@ int tx4927_irq_nested(void)
 
 #ifdef CONFIG_TOSHIBA_RBTX4927
 			{
+				extern int toshiba_rbtx4927_irq_nested(int
+								       sw_irq);
 				sw_irq = toshiba_rbtx4927_irq_nested(sw_irq);
 			}
 #endif
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
@@ -293,8 +293,10 @@ u32 bit2num(u32 num)
 int toshiba_rbtx4927_irq_nested(int sw_irq)
 {
 	u32 level3;
+#ifdef CONFIG_TOSHIBA_FPCIB0
 	u32 level4;
 	u32 level5;
+#endif
 
 	level3 = reg_rd08(TOSHIBA_RBTX4927_IOC_INTR_STAT) & 0x1f;
 	if (level3) {
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
@@ -74,7 +74,7 @@ void __init prom_init(void)
 	else
 		mips_machtype = MACH_TOSHIBA_RBTX4937;
 
-        toshiba_name = toshiba_name_list[mips_machtype];
+        toshiba_name = (char *)toshiba_name_list[mips_machtype];
 
 	msize = tx4927_get_mem_size();
 	add_memory_region(0, msize << 20, BOOT_MEM_RAM);
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -134,6 +134,9 @@ int tx4927_using_backplane = 0;
 extern void gt64120_time_init(void);
 extern void toshiba_rbtx4927_irq_setup(void);
 
+extern char *prom_getcmdline(void);
+extern void rtc_ds1742_init(unsigned long);
+
 #ifdef CONFIG_PCI
 #define CONFIG_TX4927BUG_WORKAROUND
 #undef TX4927_SUPPORT_COMMAND_IO
@@ -268,7 +271,9 @@ static int __init tx4927_pcibios_init(vo
 			u8 v08_64;
 			u32 v32_b0;
 			u8 v08_e1;
+#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG
 			char *s = " sb/isa --";
+#endif
 
 			TOSHIBA_RBTX4927_SETUP_DPRINTK
 			    (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -353,7 +358,9 @@ static int __init tx4927_pcibios_init(vo
 			u8 v08_41;
 			u8 v08_43;
 			u8 v08_5c;
+#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG
 			char *s = " sb/ide --";
+#endif
 
 			TOSHIBA_RBTX4927_SETUP_DPRINTK
 			    (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -971,9 +978,6 @@ void __init toshiba_rbtx4927_setup(void)
 void __init
 toshiba_rbtx4927_time_init(void)
 {
-	u32 c1;
-	u32 c2;
-
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "-\n");
 
 	rtc_ds1742_init(RBTX4927_RTC_BASE);

--------------060407040209010203080500--

From vbarinov@ru.mvista.com Wed Sep 14 14:08:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 14:08:46 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.6] ([IPv6:::ffff:85.21.88.6]:3348 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225204AbVINNIY>; Wed, 14 Sep 2005 14:08:24 +0100
Received: from [192.168.12.17] ([10.149.0.1])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j8ED8Mt22013;
	Wed, 14 Sep 2005 18:08:22 +0500
Message-ID: <432820C6.2050906@ru.mvista.com>
Date:	Wed, 14 Sep 2005 17:08:22 +0400
From:	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH]  Fix module insertion fail for TX4927/TX4938 platforms
References: <20050913124544.GC3224@linux-mips.org>	<20050913133126.GO23161@lug-owl.de>	<20050913152038.GE3224@linux-mips.org> <17191.61757.80884.8289@mips.com> <43281DC3.8010602@ru.mvista.com> <43281F6E.3010807@ru.mvista.com> <43281FE6.4070102@ru.mvista.com>
In-Reply-To: <43281FE6.4070102@ru.mvista.com>
Content-Type: multipart/mixed;
 boundary="------------080609060704000107050501"
Return-Path: <vbarinov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8946
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vbarinov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1749
Lines: 54

This is a multi-part message in MIME format.
--------------080609060704000107050501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello All!

This patch fixes module insertion fail for TX4927/TX4938 platforms for 
several drivers:
*** Warning: "__wbflush" [fs/reiserfs/reiserfs.ko] undefined!
*** Warning: "__wbflush" [fs/jbd/jbd.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/net2280.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/g_serial.ko] undefined!
*** Warning: "__wbflush" [drivers/net/ppp_generic.ko] undefined!

Does it makes sence to push it in?

Regards,
Vladimir


--------------080609060704000107050501
Content-Type: text/plain;
 name="pro_mips_tx4927_modules_fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pro_mips_tx4927_modules_fix.patch"

Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
Description:
	Fix module insertion fail on TX4927/TX4938 platforms

Index: linux-2.6.10/arch/mips/tx4927/common/tx4927_setup.c
===================================================================
--- linux-2.6.10.orig/arch/mips/tx4927/common/tx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/common/tx4927_setup.c
@@ -231,3 +231,5 @@ void pk0(void)
 	printk("k0=[0x%08x]\n", val);
 }
 #endif
+
+EXPORT_SYMBOL(__wbflush);
Index: linux-2.6.10/arch/mips/tx4938/common/setup.c
===================================================================
--- linux-2.6.10.orig/arch/mips/tx4938/common/setup.c
+++ linux-2.6.10/arch/mips/tx4938/common/setup.c
@@ -89,3 +89,5 @@ void __init tx4938_timer_setup(struct ir
 	write_c0_compare(count);
 	c2 = read_c0_count();
 }
+
+EXPORT_SYMBOL(__wbflush);

--------------080609060704000107050501--

From jbglaw@lug-owl.de Wed Sep 14 16:17:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 16:17:50 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:56537 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225288AbVINPRd>;
	Wed, 14 Sep 2005 16:17:33 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 26C56F0070; Wed, 14 Sep 2005 17:17:28 +0200 (CEST)
Date:	Wed, 14 Sep 2005 17:17:28 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>
Cc:	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] Ethernet for TX4927(37) platform
Message-ID: <20050914151728.GI23161@lug-owl.de>
Mail-Followup-To: "Vladimir A. Barinov" <vbarinov@ru.mvista.com>,
	linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <17191.61757.80884.8289@mips.com> <43281DC3.8010602@ru.mvista.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="8TMLq6GPUuN4DysL"
Content-Disposition: inline
In-Reply-To: <43281DC3.8010602@ru.mvista.com>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8947
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1295
Lines: 44


--8TMLq6GPUuN4DysL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-09-14 16:55:31 +0400, Vladimir A. Barinov <vbarinov@ru.mvista.=
com> wrote:
> Hello All!
>=20
> This as a patch to add ethernet support for TX4927 platform.
> Does it makes sence to push it in?

Whenever you want to start a new thread of discussion, please do so
and don't simply press 'Reply' on some unrelated email and change the
subject line. Your patches don't correspond to the GIT discossen, so
please keep out out of it.

Thanks, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--8TMLq6GPUuN4DysL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKD8HHb1edYOZ4bsRAt/OAJ9pMBQk4Nah0D5ueMzVNhElaiub5gCeMHUj
z//Edqhr5TcdAJbDOcB0sb8=
=x/hd
-----END PGP SIGNATURE-----

--8TMLq6GPUuN4DysL--

From jbglaw@lug-owl.de Wed Sep 14 16:21:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 16:22:01 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:13716 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225305AbVINPVp>;
	Wed, 14 Sep 2005 16:21:45 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 95A73F007A; Wed, 14 Sep 2005 17:21:44 +0200 (CEST)
Date:	Wed, 14 Sep 2005 17:21:44 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050914152144.GJ23161@lug-owl.de>
Mail-Followup-To: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de> <20050914123750.GL3224@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4B4+7MsODflw+h2f"
Content-Disposition: inline
In-Reply-To: <20050914123750.GL3224@linux-mips.org>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8948
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2848
Lines: 75


--4B4+7MsODflw+h2f
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-09-14 13:37:50 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote:
> > monotone
> > 	Is quite nice'n'easy to use for CVS users, you'll have quite a
> > 	fast start. The network sync protocol can be a bit lengthy at
> > 	a time, but it works. It's acceptable in speed, but not
> > 	exactly "fast". Written in C, code can easily be read and
> > 	hacked.
>=20
> Git has taken some ideas from Monotone.

Though monotone uses a (berkeley?) DB to store all objects...

> > arch
> > 	Arch can do almost everything; it's network sync protocol is
> > 	quite fast (can use several transports and will make use of
> > 	caches). However, it's not exactly easy to use because of it's
> > 	thousands of commands and it's project name conventions are,
> > 	um, ugly. It has very good merging capabilities, but it's
> > 	heavy use of local caches forces you to have loads of free HDD
> > 	space.
>=20
> Git is a huge diskspace consumer also unless repositories are converted.
> For example, the Linux kernel repository from CVS did inflate itself to
> over 4GB and over 340,000 files.  After packing I got that down to like
> 170MB.  Not bad compared to the some 770MB of RCS files it's using
> currently and < 11s checkout from git can't be wrong either ;-)

Well, Arch *may* cache any tree version you check out. So take a
source tree and check-out some 15 tree versions, you may end up with a
really *hugh* cache. You're free to delete it, though...

> > To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> > the way[tm] to go, so we'd try to get familiar with it.
>=20
> The other accepted currency of the trade are still simple patches, see
> http://www.linux-mips.org/wiki/The_perfect_patch.

ACK. But unless you've got the perfect Patch Queue Manager that'll
re-diff and re-send your patches automatically to Linus, you keep on
doing some manual work or at least starting your scripts ever and ever
again :)

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--4B4+7MsODflw+h2f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD4DBQFDKEAIHb1edYOZ4bsRAn1UAJ4hrFzvlb5zNDVpYHOb37RkYR1I+gCY/rwG
jHly3e0FX0dUEOKa057PjQ==
=eKma
-----END PGP SIGNATURE-----

--4B4+7MsODflw+h2f--

From nigel@mips.com Wed Sep 14 16:27:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 16:28:12 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:62481 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225305AbVINP1w>;
	Wed, 14 Sep 2005 16:27:52 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EFZ9I-0001FL-00; Wed, 14 Sep 2005 16:26:12 +0100
Received: from highbury.mips.com ([192.168.192.236])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EFZAJ-0003r7-00; Wed, 14 Sep 2005 16:27:15 +0100
Message-ID: <43284153.1040508@mips.com>
Date:	Wed, 14 Sep 2005 16:27:15 +0100
From:	Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Debian Thunderbird 1.0.2 (X11/20050817)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
CC:	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: Git
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de> <20050914123750.GL3224@linux-mips.org> <20050914152144.GJ23161@lug-owl.de>
In-Reply-To: <20050914152144.GJ23161@lug-owl.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.84,
	required 4, AWL, BAYES_00)
Return-Path: <nigel@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8949
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 776
Lines: 27



Jan-Benedict Glaw wrote:

>>>To get fixes/port updates/subsystem updates upstream to Linus, GIT is
>>>the way[tm] to go, so we'd try to get familiar with it.
>>>      
>>>
>>The other accepted currency of the trade are still simple patches, see
>>http://www.linux-mips.org/wiki/The_perfect_patch.
>>    
>>
>
>ACK. But unless you've got the perfect Patch Queue Manager that'll
>re-diff and re-send your patches automatically to Linus, you keep on
>doing some manual work or at least starting your scripts ever and ever
>again :)
>
>  
>

Speaking of patch management, has anyone tried out Stacked GIT (aka 
StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like 
it could be useful, and can be used in conjunction with other porcelain 
like Cogito.

Nigel

From jbglaw@lug-owl.de Wed Sep 14 16:44:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 16:45:11 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:32741 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8225305AbVINPo4>;
	Wed, 14 Sep 2005 16:44:56 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 1A2F7F007F; Wed, 14 Sep 2005 17:44:53 +0200 (CEST)
Date:	Wed, 14 Sep 2005 17:44:53 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	Nigel Stephens <nigel@mips.com>
Cc:	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: Git
Message-ID: <20050914154453.GL23161@lug-owl.de>
Mail-Followup-To: Nigel Stephens <nigel@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de> <20050914123750.GL3224@linux-mips.org> <20050914152144.GJ23161@lug-owl.de> <43284153.1040508@mips.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="3iqGNvuhWAyawlAA"
Content-Disposition: inline
In-Reply-To: <43284153.1040508@mips.com>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8950
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1787
Lines: 56


--3iqGNvuhWAyawlAA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Ni Nigel!

On Wed, 2005-09-14 16:27:15 +0100, Nigel Stephens <nigel@mips.com> wrote:
> Jan-Benedict Glaw wrote:
> >>>To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> >>>the way[tm] to go, so we'd try to get familiar with it.
> >>The other accepted currency of the trade are still simple patches, see
> >>http://www.linux-mips.org/wiki/The_perfect_patch.
> >
> >ACK. But unless you've got the perfect Patch Queue Manager that'll
> >re-diff and re-send your patches automatically to Linus, you keep on
> >doing some manual work or at least starting your scripts ever and ever
> >again :)
>=20
> Speaking of patch management, has anyone tried out Stacked GIT (aka=20
> StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like=
=20
> it could be useful, and can be used in conjunction with other porcelain=
=20
> like Cogito.

No, not yet, mostly due to time reasons. But I second it sounds
useful.=20

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--3iqGNvuhWAyawlAA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKEV1Hb1edYOZ4bsRAkSRAJ43wIoDZat3Oh57WERq02iciQZO4gCfeiex
QQpB4cA8K6GEE+M9Tdmv1GM=
=ZHeB
-----END PGP SIGNATURE-----

--3iqGNvuhWAyawlAA--

From bruno.randolf@4g-systems.biz Wed Sep 14 17:29:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 17:30:05 +0100 (BST)
Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:15624 "EHLO
	grey.subnet.at") by linux-mips.org with ESMTP id <S8225337AbVINQ3q>;
	Wed, 14 Sep 2005 17:29:46 +0100
Received: from ip6-localhost ([193.170.141.4]) by grey.subnet.at ; Wed, 14 Sep 2005 18:29:40 +0200
From:	Bruno Randolf <bruno.randolf@4g-systems.biz>
To:	linux-mips@linux-mips.org, ppopov@embeddedalley.com
Subject: [patch] little zImage.flash fixes
Date:	Wed, 14 Sep 2005 18:25:29 +0200
User-Agent: KMail/1.8.1
Organization: 4G Systems
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1279673.Wg4iRfG56D";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200509141825.34038.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8951
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips
Content-Length: 4190
Lines: 129

--nextPart1279673.Wg4iRfG56D
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hello!

fyi - i had to make the following changes after applying your=20
zImage_2_6_10.patch to use "make zImage.flash" on the recent 2.6.13=20
linux-mips kernel.  also "make zImage" wouldn't compile through without the=
=20
"-I $(TOPDIR)/include" changes.

greetings,
bruno

=2D--

diff --exclude CVS -Nurb linux/arch/mips/Makefile=20
linux-2.6.13/arch/mips/Makefile
=2D-- linux/arch/mips/Makefile=A0=A0=A0=A02005-09-14 16:44:32.000000000 +02=
00
+++ linux-2.6.13/arch/mips/Makefile=A0=A0=A0=A0=A02005-09-14 16:32:28.00000=
0000 +0200
@@ -798,6 +798,9 @@
=A0zImage: vmlinux
=A0=A0=A0=A0=A0=A0=A0=A0+@$(call makeboot,$@)
=A0
+zImage.flash: vmlinux
+=A0=A0=A0=A0=A0=A0=A0+@$(call makeboot,$@)
+
=A0CLEAN_FILES +=3D vmlinux.ecoff \
=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 vmlinux.srec \
=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 vmlinux.rm200.tmp \
diff --exclude CVS -Nurb linux/arch/mips/boot/Makefile=20
linux-2.6.13/arch/mips/boot/Makefile
=2D-- linux/arch/mips/boot/Makefile=A0=A0=A0=A0=A0=A0=A02005-09-14 16:44:32=
=2E000000000 +0200
+++ linux-2.6.13/arch/mips/boot/Makefile=A0=A0=A0=A0=A0=A0=A0=A02005-09-14 =
16:35:14.000000000=20
+0200
@@ -26,7 +26,7 @@
=A0
=A0VMLINUX =3D vmlinux
=A0
=2DZBOOT_TARGETS=A0=A0=3D zImage
+ZBOOT_TARGETS=A0=A0=3D zImage zImage.flash
=A0bootdir-y=A0=A0=A0=A0=A0=A0:=3D compressed
=A0
=A0all: vmlinux.ecoff vmlinux.srec addinitrd zImage
diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/Makefile=20
linux-2.6.13/arch/mips/boot/compressed/Makefile
=2D-- linux/arch/mips/boot/compressed/Makefile=A0=A0=A0=A02005-09-14 16:44:=
32.000000000=20
+0200
+++ linux-2.6.13/arch/mips/boot/compressed/Makefile=A0=A0=A0=A0=A02005-09-1=
4=20
16:31:53.000000000 +0200
@@ -18,7 +18,7 @@
=A0
=A0CFLAGS=A0 =A0=A0=A0=A0=A0=A0=A0+=3D -fno-builtin -D__BOOTER__ -I$(compre=
ssed)/include
=A0
=2DBOOT_TARGETS=A0=A0=A0=3D zImage=20
+BOOT_TARGETS=A0=A0=A0=3D zImage zImage.flash
=A0
=A0bootdir-$(CONFIG_SOC_AU1X00)=A0=A0=A0:=3D au1xxx
=A0subdir-y=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0:=3D common lib images
diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/au1xxx/Makefile=20
linux-2.6.13/arch/mips/boot/compressed/au1xxx/Makefile
=2D-- linux/arch/mips/boot/compressed/au1xxx/Makefile=A0=A0=A0=A0=A02005-09=
=2D14=20
16:44:32.000000000 +0200
+++ linux-2.6.13/arch/mips/boot/compressed/au1xxx/Makefile=A0=A0=A0=A0=A0=
=A02005-09-14=20
16:38:34.000000000 +0200
@@ -73,12 +73,12 @@
=A0endif
=A0
=A0$(obj)/head.o: $(obj)/head.S $(TOPDIR)/vmlinux
=2D=A0=A0=A0=A0=A0=A0=A0$(CC) $(AFLAGS) \
+=A0=A0=A0=A0=A0=A0=A0$(CC) -I $(TOPDIR)/include $(AFLAGS) \
=A0=A0=A0=A0=A0=A0=A0=A0-DKERNEL_ENTRY=3D$(shell sh $(ENTRY) $(NM) $(TOPDIR=
)/vmlinux ) \
=A0=A0=A0=A0=A0=A0=A0=A0-c -o $*.o $<
=A0
=A0$(common)/misc-simple.o:
=2D=A0=A0=A0=A0=A0=A0=A0$(CC) $(CFLAGS) -DINITRD_OFFSET=3D0 -DINITRD_SIZE=
=3D0 -DZIMAGE_OFFSET=3D0 \
+=A0=A0=A0=A0=A0=A0=A0$(CC) -I $(TOPDIR)/include $(CFLAGS) -DINITRD_OFFSET=
=3D0 -DINITRD_SIZE=3D0=20
=2DDZIMAGE_OFFSET=3D0 \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-DAVAIL_RAM_START=3D$(AVAIL=
_RAM_START) \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-DAVAIL_RAM_END=3D$(AVAIL_R=
AM_END) \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-DLOADADDR=3D$(LOADADDR) \
diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/common/misc-simple=
=2Ec=20
linux-2.6.13/arch/mips/boot/compressed/common/misc-simple.c
=2D-- linux/arch/mips/boot/compressed/common/misc-simple.c=A0=A0=A0=A0=A0=
=A0=A0=A02005-09-14=20
16:44:32.000000000 +0200
+++ linux-2.6.13/arch/mips/boot/compressed/common/misc-simple.c=A02005-09-1=
4=20
16:31:07.000000000 +0200
@@ -24,7 +24,7 @@
=A0
=A0#include <asm/page.h>
=A0
=2D#include "zlib.h"
+#include "linux/zlib.h"
=A0
=A0extern struct NS16550 *com_port;

--nextPart1279673.Wg4iRfG56D
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDKE7+fg2jtUL97G4RAq14AJ9q4sf4Ba0FNL68pGYBadz9omHEzwCfYsXB
TQxrpJxNlUx25CkkeOGCSb0=
=4Oqb
-----END PGP SIGNATURE-----

--nextPart1279673.Wg4iRfG56D--

From adobriyan@gmail.com Wed Sep 14 19:17:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 19:18:00 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.205]:49210 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8224992AbVINSRn>;
	Wed, 14 Sep 2005 19:17:43 +0100
Received: by zproxy.gmail.com with SMTP id j2so7596nzf
        for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 11:17:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent;
        b=WdAjxnM9aL3rNzifE6F8gKEn2DZh/xIyCn5g38RyNY8JG067/6Llk6U9fPMFz6jRUa3rGAonSxAvzWMv3dKHl5ybjSFw7pR/yXKU8XXEOxPThKD4jG3hD5TKZE6+lK1Fo+1LPzF2e/ahbBLJelgtq6oalX5EIAhrU+cQfXPN9LU=
Received: by 10.36.96.5 with SMTP id t5mr1879361nzb;
        Wed, 14 Sep 2005 11:17:31 -0700 (PDT)
Received: from gmail.com ( [217.10.38.130])
        by mx.gmail.com with ESMTP id r15sm40027nza.2005.09.14.11.17.28;
        Wed, 14 Sep 2005 11:17:30 -0700 (PDT)
Received: by gmail.com (nbSMTP-1.00) for uid 1000
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
	adobriyan@gmail.com; Wed, 14 Sep 2005 22:27:48 +0400 (MSD)
Date:	Wed, 14 Sep 2005 22:27:45 +0400
From:	Alexey Dobriyan <adobriyan@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Clemens Buchacher <drizzd@aon.at>, linux-mips@linux-mips.org
Subject: [PATCH] mips: don't concatenate __FUNCTION__ with strings
Message-ID: <20050914182745.GC19491@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <adobriyan@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8952
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adobriyan@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2664
Lines: 76

From: Clemens Buchacher <drizzd@aon.at>

It's deprecated. Use "%s", __FUNCTION__ instead.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>

--- a/arch/mips/au1000/common/usbdev.c
+++ b/arch/mips/au1000/common/usbdev.c
@@ -348,7 +348,7 @@ endpoint_stall(endpoint_t * ep)
 {
 	u32 cs;
 
-	warn(__FUNCTION__);
+	warn("%s", __FUNCTION__);
 
 	cs = au_readl(ep->reg->ctrl_stat) | USBDEV_CS_STALL;
 	au_writel(cs, ep->reg->ctrl_stat);
@@ -360,7 +360,7 @@ endpoint_unstall(endpoint_t * ep)
 {
 	u32 cs;
 
-	warn(__FUNCTION__);
+	warn("%s", __FUNCTION__);
 
 	cs = au_readl(ep->reg->ctrl_stat) & ~USBDEV_CS_STALL;
 	au_writel(cs, ep->reg->ctrl_stat);
--- a/drivers/net/gt96100eth.c
+++ b/drivers/net/gt96100eth.c
@@ -72,8 +72,6 @@ static void dump_tx_desc(int dbg_lvl, st
 static void dump_rx_desc(int dbg_lvl, struct net_device *dev, int i);
 static void dump_skb(int dbg_lvl, struct net_device *dev,
 		     struct sk_buff *skb);
-static void dump_hw_addr(int dbg_lvl, struct net_device *dev,
-			 const char* pfx, unsigned char* addr_str);
 static void update_stats(struct gt96100_private *gp);
 static void abort(struct net_device *dev, u32 abort_bits);
 static void hard_stop(struct net_device *dev);
@@ -334,13 +332,13 @@ dump_MII(int dbg_lvl, struct net_device 
 
 static void
 dump_hw_addr(int dbg_lvl, struct net_device *dev, const char* pfx,
-	     unsigned char* addr_str)
+	     const char* func, unsigned char* addr_str)
 {
 	int i;
 	char buf[100], octet[5];
     
 	if (dbg_lvl <= GT96100_DEBUG) {
-		strcpy(buf, pfx);
+		sprintf(buf, pfx, func);
 		for (i = 0; i < 6; i++) {
 			sprintf(octet, "%2.2x%s",
 				addr_str[i], i<5 ? ":" : "\n");
@@ -708,7 +706,7 @@ static int __init gt96100_probe1(struct 
 
 	info("%s found at 0x%x, irq %d\n",
 	     chip_name(gp->chip_rev), gtif->iobase, gtif->irq);
-	dump_hw_addr(0, dev, "HW Address ", dev->dev_addr);
+	dump_hw_addr(0, dev, "%s: HW Address ", __FUNCTION__, dev->dev_addr);
 	info("%s chip revision=%d\n", chip_name(gp->chip_rev), gp->chip_rev);
 	info("%s ethernet port %d\n", chip_name(gp->chip_rev), gp->port_num);
 	info("external PHY ID1=0x%04x, ID2=0x%04x\n", phy_id1, phy_id2);
@@ -1488,7 +1486,7 @@ gt96100_set_rx_mode(struct net_device *d
 		gt96100_add_hash_entry(dev, dev->dev_addr);
 
 		for (mcptr = dev->mc_list; mcptr; mcptr = mcptr->next) {
-			dump_hw_addr(2, dev, __FUNCTION__ ": addr=",
+			dump_hw_addr(2, dev, "%s: addr=", __FUNCTION__,
 				     mcptr->dmi_addr);
 			gt96100_add_hash_entry(dev, mcptr->dmi_addr);
 		}



From adobriyan@gmail.com Wed Sep 14 19:41:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 19:41:53 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.201]:9593 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8224982AbVINSlf>;
	Wed, 14 Sep 2005 19:41:35 +0100
Received: by zproxy.gmail.com with SMTP id 34so10648nzf
        for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 11:41:28 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent;
        b=XpM2YT5Qt5vXVn6uDn1GlSq9MhW5Op14opW910fxRzW+CewWDjA0oMwmwQJZ4cZIJiAYEWd4AWdAS1xMer83mwzLlAJMx5VXIHa3tGwY40Dd5kN5bFOKy+mG06R2oT18mRYU3CEHI/cCj3gqWly0hUcrsZQhZWT/1our2OzwIxY=
Received: by 10.36.3.20 with SMTP id 20mr909033nzc;
        Wed, 14 Sep 2005 11:41:26 -0700 (PDT)
Received: from gmail.com ( [217.10.38.130])
        by mx.gmail.com with ESMTP id 37sm70593nzf.2005.09.14.11.41.20;
        Wed, 14 Sep 2005 11:41:24 -0700 (PDT)
Received: by gmail.com (nbSMTP-1.00) for uid 1000
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
	adobriyan@gmail.com; Wed, 14 Sep 2005 22:51:41 +0400 (MSD)
Date:	Wed, 14 Sep 2005 22:51:37 +0400
From:	Alexey Dobriyan <adobriyan@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Scott Feldman <sfeldma@pobox.com>, netdev@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: [PATCH] gt96100: stop using pci_find_device()
Message-ID: <20050914185136.GE19491@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <adobriyan@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8953
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adobriyan@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1372
Lines: 44

From: Scott Feldman <sfeldma@pobox.com>

Replace pci_find_device with pci_get_device/pci_dev_put to plug race
with pci_find_device.

Signed-off-by: Scott Feldman <sfeldma@pobox.com>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 drivers/net/gt96100eth.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/gt96100eth.c
+++ b/drivers/net/gt96100eth.c
@@ -615,9 +615,9 @@ static int gt96100_init_module(void)
 	/*
 	 * Stupid probe because this really isn't a PCI device
 	 */
-	if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
+	if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
 	                            PCI_DEVICE_ID_MARVELL_GT96100, NULL)) &&
-	    !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
+	    !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
 		                    PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) {
 		printk(KERN_ERR __FILE__ ": GT96100 not found!\n");
 		return -ENODEV;
@@ -627,12 +627,14 @@ static int gt96100_init_module(void)
 	if (cpuConfig & (1<<12)) {
 		printk(KERN_ERR __FILE__
 		       ": must be in Big Endian mode!\n");
+		pci_dev_put(pci);
 		return -ENODEV;
 	}
 
 	for (i=0; i < NUM_INTERFACES; i++)
 		retval |= gt96100_probe1(pci, i);
 
+	pci_dev_put(pci);
 	return retval;
 }
 


From jgarzik@pobox.com Wed Sep 14 20:01:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 20:01:24 +0100 (BST)
Received: from mail.dvmed.net ([IPv6:::ffff:216.237.124.58]:44978 "EHLO
	mail.dvmed.net") by linux-mips.org with ESMTP id <S8225003AbVINTBI>;
	Wed, 14 Sep 2005 20:01:08 +0100
Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88])
	by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux))
	id 1EFcVA-0002eC-Hb; Wed, 14 Sep 2005 19:01:02 +0000
Message-ID: <4328736A.8040803@pobox.com>
Date:	Wed, 14 Sep 2005 15:00:58 -0400
From:	Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Alexey Dobriyan <adobriyan@gmail.com>
CC:	Ralf Baechle <ralf@linux-mips.org>,
	Scott Feldman <sfeldma@pobox.com>, netdev@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] gt96100: stop using pci_find_device()
References: <20050914185136.GE19491@mipter.zuzino.mipt.ru>
In-Reply-To: <20050914185136.GE19491@mipter.zuzino.mipt.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jgarzik@pobox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8954
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1399
Lines: 42

Alexey Dobriyan wrote:
> From: Scott Feldman <sfeldma@pobox.com>
> 
> Replace pci_find_device with pci_get_device/pci_dev_put to plug race
> with pci_find_device.
> 
> Signed-off-by: Scott Feldman <sfeldma@pobox.com>
> Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
> Signed-off-by: Domen Puncer <domen@coderock.org>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
> 
>  drivers/net/gt96100eth.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> --- a/drivers/net/gt96100eth.c
> +++ b/drivers/net/gt96100eth.c
> @@ -615,9 +615,9 @@ static int gt96100_init_module(void)
>  	/*
>  	 * Stupid probe because this really isn't a PCI device
>  	 */
> -	if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
> +	if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
>  	                            PCI_DEVICE_ID_MARVELL_GT96100, NULL)) &&
> -	    !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
> +	    !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
>  		                    PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) {
>  		printk(KERN_ERR __FILE__ ": GT96100 not found!\n");
>  		return -ENODEV;
> @@ -627,12 +627,14 @@ static int gt96100_init_module(void)
>  	if (cpuConfig & (1<<12)) {
>  		printk(KERN_ERR __FILE__
>  		       ": must be in Big Endian mode!\n");
> +		pci_dev_put(pci);
>  		return -ENODEV;

NAK -- convert it to use standard PCI driver API.

	Jeff




From ralf@linux-mips.org Wed Sep 14 20:41:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 20:41:17 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:43025 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8224982AbVINTlC>; Wed, 14 Sep 2005 20:41:02 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8EJeg4A010849;
	Wed, 14 Sep 2005 20:40:42 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8EJecXV010820;
	Wed, 14 Sep 2005 20:40:39 +0100
Date:	Wed, 14 Sep 2005 20:40:38 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Alexey Dobriyan <adobriyan@gmail.com>
Cc:	Scott Feldman <sfeldma@pobox.com>, netdev@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] gt96100: stop using pci_find_device()
Message-ID: <20050914194038.GP3224@linux-mips.org>
References: <20050914185136.GE19491@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050914185136.GE19491@mipter.zuzino.mipt.ru>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8955
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 268
Lines: 9

On Wed, Sep 14, 2005 at 10:51:37PM +0400, Alexey Dobriyan wrote:

> Replace pci_find_device with pci_get_device/pci_dev_put to plug race
> with pci_find_device.

The system is a little odd; the race condition probably doens't exist on
this particular chipset.

  Ralf

From adobriyan@gmail.com Wed Sep 14 20:49:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 20:49:33 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.204]:58345 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8224982AbVINTtP>;
	Wed, 14 Sep 2005 20:49:15 +0100
Received: by zproxy.gmail.com with SMTP id j2so22975nzf
        for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 12:49:09 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent;
        b=Clp8IQqkEGtCyCBxyqQSeGudr+Zgif+du2oYs0d5pXqniammiJp+Bz1HjU9PyHfZ30+Gmt1ufthstiahsZGdv0Cfp56wq96G+PE4yRVLMMpT6gWSnxG+SqiaWTzwQLorh6e6BM+VrWwIz3mbs6TOcF0T8jus4+YiCESSAqVCt4I=
Received: by 10.36.96.5 with SMTP id t5mr1962925nzb;
        Wed, 14 Sep 2005 12:49:02 -0700 (PDT)
Received: from gmail.com ( [217.10.38.130])
        by mx.gmail.com with ESMTP id 10sm151704nzo.2005.09.14.12.48.55;
        Wed, 14 Sep 2005 12:48:58 -0700 (PDT)
Received: by gmail.com (nbSMTP-1.00) for uid 1000
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
	adobriyan@gmail.com; Wed, 14 Sep 2005 23:59:16 +0400 (MSD)
Date:	Wed, 14 Sep 2005 23:59:11 +0400
From:	Alexey Dobriyan <adobriyan@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org, Domen Puncer <domen@coderock.org>
Subject: [PATCH] Remove arch/mips/arc/salone.c
Message-ID: <20050914195911.GH19491@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <adobriyan@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8956
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adobriyan@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1123
Lines: 39

From: Domen Puncer <domen@coderock.org>

Remove nowhere referenced file (grep salone -r . didn't find anything).

Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 arch/mips/arc/salone.c |   24 ------------------------
 1 files changed, 24 deletions(-)

--- a/arch/mips/arc/salone.c	2005-09-14 19:05:26.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,24 +0,0 @@
-/*
- * Routines to load into memory and execute stand-along program images using
- * ARCS PROM firmware.
- *
- * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
- */
-#include <linux/init.h>
-#include <asm/sgialib.h>
-
-LONG __init ArcLoad(CHAR *Path, ULONG TopAddr, ULONG *ExecAddr, ULONG *LowAddr)
-{
-	return ARC_CALL4(load, Path, TopAddr, ExecAddr, LowAddr);
-}
-
-LONG __init ArcInvoke(ULONG ExecAddr, ULONG StackAddr, ULONG Argc, CHAR *Argv[],
-	CHAR *Envp[])
-{
-	return ARC_CALL5(invoke, ExecAddr, StackAddr, Argc, Argv, Envp);
-}
-
-LONG __init ArcExecute(CHAR *Path, LONG Argc, CHAR *Argv[], CHAR *Envp[])
-{
-	return ARC_CALL4(exec, Path, Argc, Argv, Envp);
-}


From adobriyan@gmail.com Wed Sep 14 20:54:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 20:55:12 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.197]:16827 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8225196AbVINTyq>;
	Wed, 14 Sep 2005 20:54:46 +0100
Received: by zproxy.gmail.com with SMTP id v1so19804nzb
        for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 12:54:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent;
        b=O0vkB9E6MafExzywIoEW6oI9BlGunFOj+Ux77zfFSASTikfd5uqJDbaKkcuzdz3voiuNkcpiyyBxmv+neQBGjrxO1/tMLL6rCCWQaxB5LEdi+zjyTgk/BTlketSZwI8uLJOcANBrXn5chNWjNgFfCzCVCUJz119OT50IkBrI2VY=
Received: by 10.36.41.6 with SMTP id o6mr438148nzo;
        Wed, 14 Sep 2005 12:54:33 -0700 (PDT)
Received: from gmail.com ( [217.10.38.130])
        by mx.gmail.com with ESMTP id 6sm154505nzn.2005.09.14.12.54.26;
        Wed, 14 Sep 2005 12:54:31 -0700 (PDT)
Received: by gmail.com (nbSMTP-1.00) for uid 1000
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
	adobriyan@gmail.com; Thu, 15 Sep 2005 00:04:49 +0400 (MSD)
Date:	Thu, 15 Sep 2005 00:04:43 +0400
From:	Alexey Dobriyan <adobriyan@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org, Domen Puncer <domen@coderock.org>
Subject: [PATCH] Remove arch/mips/pmc-sierra/yosemite/ht-irq.c
Message-ID: <20050914200442.GI19491@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <adobriyan@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8957
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adobriyan@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2511
Lines: 68

From: Domen Puncer <domen@coderock.org>

Remove nowhere referenced file (grep ht-irq -r . didn't find anything).

Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

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

--- a/arch/mips/pmc-sierra/yosemite/ht-irq.c	2005-09-14 19:05:25.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,53 +0,0 @@
-/*
- * Copyright 2003 PMC-Sierra
- * Author: Manish Lachwani (lachwani@pmc-sierra.com)
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- *
- *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
- *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
- *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
- *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the  GNU General Public License along
- *  with this program; if not, write  to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include <linux/types.h>
-#include <linux/pci.h>
-#include <linux/kernel.h>
-#include <linux/version.h>
-#include <linux/init.h>
-#include <asm/pci.h>
-
-/*
- * HT Bus fixup for the Titan
- * XXX IRQ values need to change based on the board layout
- */
-void __init titan_ht_pcibios_fixup_bus(struct pci_bus *bus)
-{
-        struct pci_bus *current_bus = bus;
-        struct pci_dev *devices;
-        struct list_head *devices_link;
-
-	list_for_each(devices_link, &(current_bus->devices)) {
-                devices = pci_dev_b(devices_link);
-                if (devices == NULL)
-                        continue;
-	}
-
-	/*
-	 * PLX and SPKT related changes go here
-	 */
-
-}


From adobriyan@gmail.com Wed Sep 14 21:49:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 21:50:07 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.196]:12773 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8225003AbVINUtc>;
	Wed, 14 Sep 2005 21:49:32 +0100
Received: by zproxy.gmail.com with SMTP id 34so29097nzf
        for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 13:49:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent;
        b=bLDfSt5VcS06N8gUDDyH85bgSo2nSOthVY+EbHlu3n1huzg3b2tqIQuijABwUda8Oe8ufP0ep630+Ln0QFGGCRdzxmGV787sQ2SqbQV0JyZ0Xq5w+Irx0HmWYHJQHvbQ7WXyHBZhJ2ivLaygGFJW5aQvOko5OAxk10cgpHglSr4=
Received: by 10.36.158.15 with SMTP id g15mr1287705nze;
        Wed, 14 Sep 2005 13:49:22 -0700 (PDT)
Received: from gmail.com ( [217.10.38.130])
        by mx.gmail.com with ESMTP id 14sm255017nzp.2005.09.14.13.49.15;
        Wed, 14 Sep 2005 13:49:22 -0700 (PDT)
Received: by gmail.com (nbSMTP-1.00) for uid 1000
	(using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
	adobriyan@gmail.com; Thu, 15 Sep 2005 00:59:37 +0400 (MSD)
Date:	Thu, 15 Sep 2005 00:59:31 +0400
From:	Alexey Dobriyan <adobriyan@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Domen Puncer <domen@coderock.org>, linux-mips@linux-mips.org
Subject: [PATCH] Remove unused files from include/asm-mips/
Message-ID: <20050914205931.GA27783@mipter.zuzino.mipt.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <adobriyan@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8958
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: adobriyan@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 57513
Lines: 1345

From: Domen Puncer <domen@coderock.org>

grep "gfx\." -r .
grep au1100_mmc -r .
grep mipsprom -r .
grep riscos -r .

haven't found anything relevant.

Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 include/asm-mips/gfx.h                    |   55 -
 include/asm-mips/mach-au1x00/au1100_mmc.h |  205 ------
 include/asm-mips/mipsprom.h               |   74 --
 include/asm-mips/riscos-syscall.h         |  979 ------------------------------
 4 files changed, 1313 deletions(-)

--- a/include/asm-mips/gfx.h	2005-09-14 19:05:25.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,55 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * This is the user-visible SGI GFX interface.
- *
- * This must be used verbatim into the GNU libc.  It does not include
- * any kernel-only bits on it.
- *
- * miguel@nuclecu.unam.mx
- */
-#ifndef _ASM_GFX_H
-#define _ASM_GFX_H
-
-/* The iocls, yes, they do not make sense, but such is life */
-#define GFX_BASE             100
-#define GFX_GETNUM_BOARDS    (GFX_BASE + 1)
-#define GFX_GETBOARD_INFO    (GFX_BASE + 2)
-#define GFX_ATTACH_BOARD     (GFX_BASE + 3)
-#define GFX_DETACH_BOARD     (GFX_BASE + 4)
-#define GFX_IS_MANAGED       (GFX_BASE + 5)
-
-#define GFX_MAPALL           (GFX_BASE + 10)
-#define GFX_LABEL            (GFX_BASE + 11)
-
-#define GFX_INFO_NAME_SIZE  16
-#define GFX_INFO_LABEL_SIZE 16
-
-struct gfx_info {
-	char name  [GFX_INFO_NAME_SIZE];  /* board name */
-	char label [GFX_INFO_LABEL_SIZE]; /* label name */
-	unsigned short int xpmax, ypmax;  /* screen resolution */
-	unsigned int lenght;	          /* size of a complete gfx_info for this board */
-};
-
-struct gfx_getboardinfo_args {
-	unsigned int board;     /* board number.  starting from zero */
-	void *buf;              /* pointer to gfx_info */
-	unsigned int len;       /* buffer size of buf */
-};
-
-struct gfx_attach_board_args {
-	unsigned int board;	/* board number, starting from zero */
-	void        *vaddr;	/* address where the board registers should be mapped */
-};
-
-#ifdef __KERNEL__
-/* umap.c */
-extern void remove_mapping (struct vm_area_struct *vma, struct task_struct *, unsigned long, unsigned long);
-extern void *vmalloc_uncached (unsigned long size);
-extern int vmap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long size, unsigned long vaddr);
-#endif
-
-#endif /* _ASM_GFX_H */
--- a/include/asm-mips/mach-au1x00/au1100_mmc.h	2005-09-14 18:09:18.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,205 +0,0 @@
-/*
- * BRIEF MODULE DESCRIPTION
- *	Defines for using the MMC/SD controllers on the
- *      Alchemy Au1100 mips processor.
- *
- * Copyright (c) 2003 Embedded Edge, LLC.
- * Author: Embedded Edge, LLC.
- *         	dan@embeddededge.com or tim@embeddededge.com
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  option) any later version.
- *
- *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
- *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
- *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
- *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the  GNU General Public License along
- *  with this program; if not, write  to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-/*
- * AU1100 MMC/SD definitions.
- *
- * From "AMD Alchemy Solutions Au1100 Processor Data Book - Preliminary"
- *    June, 2003
- */
-
-#ifndef __ASM_AU1100_MMC_H
-#define __ASM_AU1100_MMC_H
-
-
-#define NUM_AU1100_MMC_CONTROLLERS	2
-
-
-#define AU1100_SD_IRQ	2
-
-
-#define SD0_BASE	0xB0600000
-#define SD1_BASE	0xB0680000
-
-
-/*
- *  Register offsets.
- */
-#define SD_TXPORT	(0x0000)
-#define SD_RXPORT	(0x0004)
-#define SD_CONFIG	(0x0008)
-#define SD_ENABLE	(0x000C)
-#define SD_CONFIG2	(0x0010)
-#define SD_BLKSIZE	(0x0014)
-#define SD_STATUS	(0x0018)
-#define SD_DEBUG	(0x001C)
-#define SD_CMD		(0x0020)
-#define SD_CMDARG	(0x0024)
-#define SD_RESP3	(0x0028)
-#define SD_RESP2	(0x002C)
-#define SD_RESP1	(0x0030)
-#define SD_RESP0	(0x0034)
-#define SD_TIMEOUT	(0x0038)
-
-
-/*
- *  SD_TXPORT bit definitions.
- */
-#define SD_TXPORT_TXD	(0x000000ff)
-
-
-/*
- *  SD_RXPORT bit definitions.
- */
-#define SD_RXPORT_RXD	(0x000000ff)
-
-
-/*
- *  SD_CONFIG bit definitions.
- */
-#define SD_CONFIG_DIV	(0x000001ff)
-#define SD_CONFIG_DE	(0x00000200)
-#define SD_CONFIG_NE	(0x00000400)
-#define SD_CONFIG_TU	(0x00000800)
-#define SD_CONFIG_TO	(0x00001000)
-#define SD_CONFIG_RU	(0x00002000)
-#define SD_CONFIG_RO	(0x00004000)
-#define SD_CONFIG_I	(0x00008000)
-#define SD_CONFIG_CR	(0x00010000)
-#define SD_CONFIG_RAT	(0x00020000)
-#define SD_CONFIG_DD	(0x00040000)
-#define SD_CONFIG_DT	(0x00080000)
-#define SD_CONFIG_SC	(0x00100000)
-#define SD_CONFIG_RC	(0x00200000)
-#define SD_CONFIG_WC	(0x00400000)
-#define SD_CONFIG_xxx	(0x00800000)
-#define SD_CONFIG_TH	(0x01000000)
-#define SD_CONFIG_TE	(0x02000000)
-#define SD_CONFIG_TA	(0x04000000)
-#define SD_CONFIG_RH	(0x08000000)
-#define SD_CONFIG_RA	(0x10000000)
-#define SD_CONFIG_RF	(0x20000000)
-#define SD_CONFIG_CD	(0x40000000)
-#define SD_CONFIG_SI	(0x80000000)
-
-
-/*
- *  SD_ENABLE bit definitions.
- */
-#define SD_ENABLE_CE	(0x00000001)
-#define SD_ENABLE_R	(0x00000002)
-
-
-/*
- *  SD_CONFIG2 bit definitions.
- */
-#define SD_CONFIG2_EN	(0x00000001)
-#define SD_CONFIG2_FF	(0x00000002)
-#define SD_CONFIG2_xx1	(0x00000004)
-#define SD_CONFIG2_DF	(0x00000008)
-#define SD_CONFIG2_DC	(0x00000010)
-#define SD_CONFIG2_xx2	(0x000000e0)
-#define SD_CONFIG2_WB	(0x00000100)
-#define SD_CONFIG2_RW	(0x00000200)
-
-
-/*
- *  SD_BLKSIZE bit definitions.
- */
-#define SD_BLKSIZE_BS	(0x000007ff)
-#define SD_BLKSIZE_BS_SHIFT	 (0)
-#define SD_BLKSIZE_BC	(0x01ff0000)
-#define SD_BLKSIZE_BC_SHIFT	(16)
-
-
-/*
- *  SD_STATUS bit definitions.
- */
-#define SD_STATUS_DCRCW	(0x00000007)
-#define SD_STATUS_xx1	(0x00000008)
-#define SD_STATUS_CB	(0x00000010)
-#define SD_STATUS_DB	(0x00000020)
-#define SD_STATUS_CF	(0x00000040)
-#define SD_STATUS_D3	(0x00000080)
-#define SD_STATUS_xx2	(0x00000300)
-#define SD_STATUS_NE	(0x00000400)
-#define SD_STATUS_TU	(0x00000800)
-#define SD_STATUS_TO	(0x00001000)
-#define SD_STATUS_RU	(0x00002000)
-#define SD_STATUS_RO	(0x00004000)
-#define SD_STATUS_I	(0x00008000)
-#define SD_STATUS_CR	(0x00010000)
-#define SD_STATUS_RAT	(0x00020000)
-#define SD_STATUS_DD	(0x00040000)
-#define SD_STATUS_DT	(0x00080000)
-#define SD_STATUS_SC	(0x00100000)
-#define SD_STATUS_RC	(0x00200000)
-#define SD_STATUS_WC	(0x00400000)
-#define SD_STATUS_xx3	(0x00800000)
-#define SD_STATUS_TH	(0x01000000)
-#define SD_STATUS_TE	(0x02000000)
-#define SD_STATUS_TA	(0x04000000)
-#define SD_STATUS_RH	(0x08000000)
-#define SD_STATUS_RA	(0x10000000)
-#define SD_STATUS_RF	(0x20000000)
-#define SD_STATUS_CD	(0x40000000)
-#define SD_STATUS_SI	(0x80000000)
-
-
-/*
- *  SD_CMD bit definitions.
- */
-#define SD_CMD_GO	(0x00000001)
-#define SD_CMD_RY	(0x00000002)
-#define SD_CMD_xx1	(0x0000000c)
-#define SD_CMD_CT_MASK	(0x000000f0)
-#define SD_CMD_CT_0	(0x00000000)
-#define SD_CMD_CT_1	(0x00000010)
-#define SD_CMD_CT_2	(0x00000020)
-#define SD_CMD_CT_3	(0x00000030)
-#define SD_CMD_CT_4	(0x00000040)
-#define SD_CMD_CT_5	(0x00000050)
-#define SD_CMD_CT_6	(0x00000060)
-#define SD_CMD_CT_7	(0x00000070)
-#define SD_CMD_CI	(0x0000ff00)
-#define SD_CMD_CI_SHIFT		(8)
-#define SD_CMD_RT_MASK	(0x00ff0000)
-#define SD_CMD_RT_0	(0x00000000)
-#define SD_CMD_RT_1	(0x00010000)
-#define SD_CMD_RT_2	(0x00020000)
-#define SD_CMD_RT_3	(0x00030000)
-#define SD_CMD_RT_4	(0x00040000)
-#define SD_CMD_RT_5	(0x00050000)
-#define SD_CMD_RT_6	(0x00060000)
-#define SD_CMD_RT_1B	(0x00810000)
-
-
-#endif /* __ASM_AU1100_MMC_H */
-
--- a/include/asm-mips/mipsprom.h	2005-09-14 18:09:18.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,74 +0,0 @@
-#ifndef __ASM_MIPS_PROM_H
-#define __ASM_MIPS_PROM_H
-
-#define PROM_RESET		0
-#define PROM_EXEC		1
-#define PROM_RESTART		2
-#define PROM_REINIT		3
-#define PROM_REBOOT		4
-#define PROM_AUTOBOOT		5
-#define PROM_OPEN		6
-#define PROM_READ		7
-#define PROM_WRITE		8
-#define PROM_IOCTL		9
-#define PROM_CLOSE		10
-#define PROM_GETCHAR		11
-#define PROM_PUTCHAR		12
-#define PROM_SHOWCHAR		13	/* XXX */
-#define PROM_GETS		14	/* XXX */
-#define PROM_PUTS		15	/* XXX */
-#define PROM_PRINTF		16	/* XXX */
-
-/* What are these for? */
-#define PROM_INITPROTO		17	/* XXX */
-#define PROM_PROTOENABLE	18	/* XXX */
-#define PROM_PROTODISABLE	19	/* XXX */
-#define PROM_GETPKT		20	/* XXX */
-#define PROM_PUTPKT		21	/* XXX */
-
-/* More PROM shit.  Probably has to do with VME RMW cycles??? */
-#define PROM_ORW_RMW		22	/* XXX */
-#define PROM_ORH_RMW		23	/* XXX */
-#define PROM_ORB_RMW		24	/* XXX */
-#define PROM_ANDW_RMW		25	/* XXX */
-#define PROM_ANDH_RMW		26	/* XXX */
-#define PROM_ANDB_RMW		27	/* XXX */
-
-/* Cache handling stuff */
-#define PROM_FLUSHCACHE		28	/* XXX */
-#define PROM_CLEARCACHE		29	/* XXX */
-
-/* Libc alike stuff */
-#define PROM_SETJMP		30	/* XXX */
-#define PROM_LONGJMP		31	/* XXX */
-#define PROM_BEVUTLB		32	/* XXX */
-#define PROM_GETENV		33	/* XXX */
-#define PROM_SETENV		34	/* XXX */
-#define PROM_ATOB		35	/* XXX */
-#define PROM_STRCMP		36	/* XXX */
-#define PROM_STRLEN		37	/* XXX */
-#define PROM_STRCPY		38	/* XXX */
-#define PROM_STRCAT		39	/* XXX */
-
-/* Misc stuff */
-#define PROM_PARSER		40	/* XXX */
-#define PROM_RANGE		41	/* XXX */
-#define PROM_ARGVIZE		42	/* XXX */
-#define PROM_HELP		43	/* XXX */
-
-/* Entry points for some PROM commands */
-#define PROM_DUMPCMD		44	/* XXX */
-#define PROM_SETENVCMD		45	/* XXX */
-#define PROM_UNSETENVCMD	46	/* XXX */
-#define PROM_PRINTENVCMD	47	/* XXX */
-#define PROM_BEVEXCEPT		48	/* XXX */
-#define PROM_ENABLECMD		49	/* XXX */
-#define PROM_DISABLECMD		50	/* XXX */
-
-#define PROM_CLEARNOFAULT	51	/* XXX */
-#define PROM_NOTIMPLEMENT	52	/* XXX */
-
-#define PROM_NV_GET		53	/* XXX */
-#define PROM_NV_SET		54	/* XXX */
-
-#endif /* __ASM_MIPS_PROM_H */
--- a/include/asm-mips/riscos-syscall.h	2005-09-14 18:09:17.000000000 +0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,979 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1995, 96, 97, 98, 99, 2000 by Ralf Baechle
- */
-#ifndef _ASM_RISCOS_SYSCALL_H
-#define _ASM_RISCOS_SYSCALL_H
-
-/*
- * The syscalls 0 - 3999 are reserved for a down to the root syscall
- * compatibility with RISC/os and IRIX.  We'll see how to deal with the
- * various "real" BSD variants like Ultrix, NetBSD ...
- */
-
-/*
- * SVR4 syscalls are in the range from 1 to 999
- */
-#define __NR_SVR4			0
-#define __NR_SVR4_syscall		(__NR_SVR4 +   0)
-#define __NR_SVR4_exit			(__NR_SVR4 +   1)
-#define __NR_SVR4_fork			(__NR_SVR4 +   2)
-#define __NR_SVR4_read			(__NR_SVR4 +   3)
-#define __NR_SVR4_write			(__NR_SVR4 +   4)
-#define __NR_SVR4_open			(__NR_SVR4 +   5)
-#define __NR_SVR4_close			(__NR_SVR4 +   6)
-#define __NR_SVR4_wait			(__NR_SVR4 +   7)
-#define __NR_SVR4_creat			(__NR_SVR4 +   8)
-#define __NR_SVR4_link			(__NR_SVR4 +   9)
-#define __NR_SVR4_unlink		(__NR_SVR4 +  10)
-#define __NR_SVR4_exec			(__NR_SVR4 +  11)
-#define __NR_SVR4_chdir			(__NR_SVR4 +  12)
-#define __NR_SVR4_gtime			(__NR_SVR4 +  13)
-#define __NR_SVR4_mknod			(__NR_SVR4 +  14)
-#define __NR_SVR4_chmod			(__NR_SVR4 +  15)
-#define __NR_SVR4_chown			(__NR_SVR4 +  16)
-#define __NR_SVR4_sbreak		(__NR_SVR4 +  17)
-#define __NR_SVR4_stat			(__NR_SVR4 +  18)
-#define __NR_SVR4_lseek			(__NR_SVR4 +  19)
-#define __NR_SVR4_getpid		(__NR_SVR4 +  20)
-#define __NR_SVR4_mount			(__NR_SVR4 +  21)
-#define __NR_SVR4_umount		(__NR_SVR4 +  22)
-#define __NR_SVR4_setuid		(__NR_SVR4 +  23)
-#define __NR_SVR4_getuid		(__NR_SVR4 +  24)
-#define __NR_SVR4_stime			(__NR_SVR4 +  25)
-#define __NR_SVR4_ptrace		(__NR_SVR4 +  26)
-#define __NR_SVR4_alarm			(__NR_SVR4 +  27)
-#define __NR_SVR4_fstat			(__NR_SVR4 +  28)
-#define __NR_SVR4_pause			(__NR_SVR4 +  29)
-#define __NR_SVR4_utime			(__NR_SVR4 +  30)
-#define __NR_SVR4_stty			(__NR_SVR4 +  31)
-#define __NR_SVR4_gtty			(__NR_SVR4 +  32)
-#define __NR_SVR4_access		(__NR_SVR4 +  33)
-#define __NR_SVR4_nice			(__NR_SVR4 +  34)
-#define __NR_SVR4_statfs		(__NR_SVR4 +  35)
-#define __NR_SVR4_sync			(__NR_SVR4 +  36)
-#define __NR_SVR4_kill			(__NR_SVR4 +  37)
-#define __NR_SVR4_fstatfs		(__NR_SVR4 +  38)
-#define __NR_SVR4_setpgrp		(__NR_SVR4 +  39)
-#define __NR_SVR4_cxenix		(__NR_SVR4 +  40)
-#define __NR_SVR4_dup			(__NR_SVR4 +  41)
-#define __NR_SVR4_pipe			(__NR_SVR4 +  42)
-#define __NR_SVR4_times			(__NR_SVR4 +  43)
-#define __NR_SVR4_profil		(__NR_SVR4 +  44)
-#define __NR_SVR4_plock			(__NR_SVR4 +  45)
-#define __NR_SVR4_setgid		(__NR_SVR4 +  46)
-#define __NR_SVR4_getgid		(__NR_SVR4 +  47)
-#define __NR_SVR4_sig			(__NR_SVR4 +  48)
-#define __NR_SVR4_msgsys		(__NR_SVR4 +  49)
-#define __NR_SVR4_sysmips		(__NR_SVR4 +  50)
-#define __NR_SVR4_sysacct		(__NR_SVR4 +  51)
-#define __NR_SVR4_shmsys		(__NR_SVR4 +  52)
-#define __NR_SVR4_semsys		(__NR_SVR4 +  53)
-#define __NR_SVR4_ioctl			(__NR_SVR4 +  54)
-#define __NR_SVR4_uadmin		(__NR_SVR4 +  55)
-#define __NR_SVR4_exch 			(__NR_SVR4 +  56)
-#define __NR_SVR4_utssys		(__NR_SVR4 +  57)
-#define __NR_SVR4_fsync			(__NR_SVR4 +  58)
-#define __NR_SVR4_exece			(__NR_SVR4 +  59)
-#define __NR_SVR4_umask			(__NR_SVR4 +  60)
-#define __NR_SVR4_chroot		(__NR_SVR4 +  61)
-#define __NR_SVR4_fcntl			(__NR_SVR4 +  62)
-#define __NR_SVR4_ulimit		(__NR_SVR4 +  63)
-#define __NR_SVR4_reserved1		(__NR_SVR4 +  64)
-#define __NR_SVR4_reserved2		(__NR_SVR4 +  65)
-#define __NR_SVR4_reserved3		(__NR_SVR4 +  66)
-#define __NR_SVR4_reserved4		(__NR_SVR4 +  67)
-#define __NR_SVR4_reserved5		(__NR_SVR4 +  68)
-#define __NR_SVR4_reserved6		(__NR_SVR4 +  69)
-#define __NR_SVR4_advfs			(__NR_SVR4 +  70)
-#define __NR_SVR4_unadvfs		(__NR_SVR4 +  71)
-#define __NR_SVR4_unused1		(__NR_SVR4 +  72)
-#define __NR_SVR4_unused2		(__NR_SVR4 +  73)
-#define __NR_SVR4_rfstart		(__NR_SVR4 +  74)
-#define __NR_SVR4_unused3		(__NR_SVR4 +  75)
-#define __NR_SVR4_rdebug		(__NR_SVR4 +  76)
-#define __NR_SVR4_rfstop		(__NR_SVR4 +  77)
-#define __NR_SVR4_rfsys			(__NR_SVR4 +  78)
-#define __NR_SVR4_rmdir			(__NR_SVR4 +  79)
-#define __NR_SVR4_mkdir			(__NR_SVR4 +  80)
-#define __NR_SVR4_getdents		(__NR_SVR4 +  81)
-#define __NR_SVR4_libattach		(__NR_SVR4 +  82)
-#define __NR_SVR4_libdetach		(__NR_SVR4 +  83)
-#define __NR_SVR4_sysfs			(__NR_SVR4 +  84)
-#define __NR_SVR4_getmsg		(__NR_SVR4 +  85)
-#define __NR_SVR4_putmsg		(__NR_SVR4 +  86)
-#define __NR_SVR4_poll			(__NR_SVR4 +  87)
-#define __NR_SVR4_lstat			(__NR_SVR4 +  88)
-#define __NR_SVR4_symlink		(__NR_SVR4 +  89)
-#define __NR_SVR4_readlink		(__NR_SVR4 +  90)
-#define __NR_SVR4_setgroups		(__NR_SVR4 +  91)
-#define __NR_SVR4_getgroups		(__NR_SVR4 +  92)
-#define __NR_SVR4_fchmod		(__NR_SVR4 +  93)
-#define __NR_SVR4_fchown		(__NR_SVR4 +  94)
-#define __NR_SVR4_sigprocmask		(__NR_SVR4 +  95)
-#define __NR_SVR4_sigsuspend		(__NR_SVR4 +  96)
-#define __NR_SVR4_sigaltstack		(__NR_SVR4 +  97)
-#define __NR_SVR4_sigaction		(__NR_SVR4 +  98)
-#define __NR_SVR4_sigpending		(__NR_SVR4 +  99)
-#define __NR_SVR4_setcontext		(__NR_SVR4 + 100)
-#define __NR_SVR4_evsys			(__NR_SVR4 + 101)
-#define __NR_SVR4_evtrapret		(__NR_SVR4 + 102)
-#define __NR_SVR4_statvfs		(__NR_SVR4 + 103)
-#define __NR_SVR4_fstatvfs		(__NR_SVR4 + 104)
-#define __NR_SVR4_reserved7		(__NR_SVR4 + 105)
-#define __NR_SVR4_nfssys		(__NR_SVR4 + 106)
-#define __NR_SVR4_waitid		(__NR_SVR4 + 107)
-#define __NR_SVR4_sigsendset		(__NR_SVR4 + 108)
-#define __NR_SVR4_hrtsys		(__NR_SVR4 + 109)
-#define __NR_SVR4_acancel		(__NR_SVR4 + 110)
-#define __NR_SVR4_async			(__NR_SVR4 + 111)
-#define __NR_SVR4_priocntlset		(__NR_SVR4 + 112)
-#define __NR_SVR4_pathconf		(__NR_SVR4 + 113)
-#define __NR_SVR4_mincore		(__NR_SVR4 + 114)
-#define __NR_SVR4_mmap			(__NR_SVR4 + 115)
-#define __NR_SVR4_mprotect		(__NR_SVR4 + 116)
-#define __NR_SVR4_munmap		(__NR_SVR4 + 117)
-#define __NR_SVR4_fpathconf		(__NR_SVR4 + 118)
-#define __NR_SVR4_vfork			(__NR_SVR4 + 119)
-#define __NR_SVR4_fchdir		(__NR_SVR4 + 120)
-#define __NR_SVR4_readv			(__NR_SVR4 + 121)
-#define __NR_SVR4_writev		(__NR_SVR4 + 122)
-#define __NR_SVR4_xstat			(__NR_SVR4 + 123)
-#define __NR_SVR4_lxstat		(__NR_SVR4 + 124)
-#define __NR_SVR4_fxstat		(__NR_SVR4 + 125)
-#define __NR_SVR4_xmknod		(__NR_SVR4 + 126)
-#define __NR_SVR4_clocal		(__NR_SVR4 + 127)
-#define __NR_SVR4_setrlimit		(__NR_SVR4 + 128)
-#define __NR_SVR4_getrlimit		(__NR_SVR4 + 129)
-#define __NR_SVR4_lchown		(__NR_SVR4 + 130)
-#define __NR_SVR4_memcntl		(__NR_SVR4 + 131)
-#define __NR_SVR4_getpmsg		(__NR_SVR4 + 132)
-#define __NR_SVR4_putpmsg		(__NR_SVR4 + 133)
-#define __NR_SVR4_rename		(__NR_SVR4 + 134)
-#define __NR_SVR4_nuname		(__NR_SVR4 + 135)
-#define __NR_SVR4_setegid		(__NR_SVR4 + 136)
-#define __NR_SVR4_sysconf		(__NR_SVR4 + 137)
-#define __NR_SVR4_adjtime		(__NR_SVR4 + 138)
-#define __NR_SVR4_sysinfo		(__NR_SVR4 + 139)
-#define __NR_SVR4_reserved8		(__NR_SVR4 + 140)
-#define __NR_SVR4_seteuid		(__NR_SVR4 + 141)
-#define __NR_SVR4_PYRAMID_statis	(__NR_SVR4 + 142)
-#define __NR_SVR4_PYRAMID_tuning	(__NR_SVR4 + 143)
-#define __NR_SVR4_PYRAMID_forcerr	(__NR_SVR4 + 144)
-#define __NR_SVR4_PYRAMID_mpcntl	(__NR_SVR4 + 145)
-#define __NR_SVR4_reserved9		(__NR_SVR4 + 146)
-#define __NR_SVR4_reserved10		(__NR_SVR4 + 147)
-#define __NR_SVR4_reserved11		(__NR_SVR4 + 148)
-#define __NR_SVR4_reserved12		(__NR_SVR4 + 149)
-#define __NR_SVR4_reserved13		(__NR_SVR4 + 150)
-#define __NR_SVR4_reserved14		(__NR_SVR4 + 151)
-#define __NR_SVR4_reserved15		(__NR_SVR4 + 152)
-#define __NR_SVR4_reserved16		(__NR_SVR4 + 153)
-#define __NR_SVR4_reserved17		(__NR_SVR4 + 154)
-#define __NR_SVR4_reserved18		(__NR_SVR4 + 155)
-#define __NR_SVR4_reserved19		(__NR_SVR4 + 156)
-#define __NR_SVR4_reserved20		(__NR_SVR4 + 157)
-#define __NR_SVR4_reserved21		(__NR_SVR4 + 158)
-#define __NR_SVR4_reserved22		(__NR_SVR4 + 159)
-#define __NR_SVR4_reserved23		(__NR_SVR4 + 160)
-#define __NR_SVR4_reserved24		(__NR_SVR4 + 161)
-#define __NR_SVR4_reserved25		(__NR_SVR4 + 162)
-#define __NR_SVR4_reserved26		(__NR_SVR4 + 163)
-#define __NR_SVR4_reserved27		(__NR_SVR4 + 164)
-#define __NR_SVR4_reserved28		(__NR_SVR4 + 165)
-#define __NR_SVR4_reserved29		(__NR_SVR4 + 166)
-#define __NR_SVR4_reserved30		(__NR_SVR4 + 167)
-#define __NR_SVR4_reserved31		(__NR_SVR4 + 168)
-#define __NR_SVR4_reserved32		(__NR_SVR4 + 169)
-#define __NR_SVR4_reserved33		(__NR_SVR4 + 170)
-#define __NR_SVR4_reserved34		(__NR_SVR4 + 171)
-#define __NR_SVR4_reserved35		(__NR_SVR4 + 172)
-#define __NR_SVR4_reserved36		(__NR_SVR4 + 173)
-#define __NR_SVR4_reserved37		(__NR_SVR4 + 174)
-#define __NR_SVR4_reserved38		(__NR_SVR4 + 175)
-#define __NR_SVR4_reserved39		(__NR_SVR4 + 176)
-#define __NR_SVR4_reserved40		(__NR_SVR4 + 177)
-#define __NR_SVR4_reserved41		(__NR_SVR4 + 178)
-#define __NR_SVR4_reserved42		(__NR_SVR4 + 179)
-#define __NR_SVR4_reserved43		(__NR_SVR4 + 180)
-#define __NR_SVR4_reserved44		(__NR_SVR4 + 181)
-#define __NR_SVR4_reserved45		(__NR_SVR4 + 182)
-#define __NR_SVR4_reserved46		(__NR_SVR4 + 183)
-#define __NR_SVR4_reserved47		(__NR_SVR4 + 184)
-#define __NR_SVR4_reserved48		(__NR_SVR4 + 185)
-#define __NR_SVR4_reserved49		(__NR_SVR4 + 186)
-#define __NR_SVR4_reserved50		(__NR_SVR4 + 187)
-#define __NR_SVR4_reserved51		(__NR_SVR4 + 188)
-#define __NR_SVR4_reserved52		(__NR_SVR4 + 189)
-#define __NR_SVR4_reserved53		(__NR_SVR4 + 190)
-#define __NR_SVR4_reserved54		(__NR_SVR4 + 191)
-#define __NR_SVR4_reserved55		(__NR_SVR4 + 192)
-#define __NR_SVR4_reserved56		(__NR_SVR4 + 193)
-#define __NR_SVR4_reserved57		(__NR_SVR4 + 194)
-#define __NR_SVR4_reserved58		(__NR_SVR4 + 195)
-#define __NR_SVR4_reserved59		(__NR_SVR4 + 196)
-#define __NR_SVR4_reserved60		(__NR_SVR4 + 197)
-#define __NR_SVR4_reserved61		(__NR_SVR4 + 198)
-#define __NR_SVR4_reserved62		(__NR_SVR4 + 199)
-#define __NR_SVR4_reserved63		(__NR_SVR4 + 200)
-#define __NR_SVR4_aread			(__NR_SVR4 + 201)
-#define __NR_SVR4_awrite		(__NR_SVR4 + 202)
-#define __NR_SVR4_listio		(__NR_SVR4 + 203)
-#define __NR_SVR4_mips_acancel		(__NR_SVR4 + 204)
-#define __NR_SVR4_astatus		(__NR_SVR4 + 205)
-#define __NR_SVR4_await			(__NR_SVR4 + 206)
-#define __NR_SVR4_areadv		(__NR_SVR4 + 207)
-#define __NR_SVR4_awritev		(__NR_SVR4 + 208)
-#define __NR_SVR4_MIPS_reserved1	(__NR_SVR4 + 209)
-#define __NR_SVR4_MIPS_reserved2	(__NR_SVR4 + 210)
-#define __NR_SVR4_MIPS_reserved3	(__NR_SVR4 + 211)
-#define __NR_SVR4_MIPS_reserved4	(__NR_SVR4 + 212)
-#define __NR_SVR4_MIPS_reserved5	(__NR_SVR4 + 213)
-#define __NR_SVR4_MIPS_reserved6	(__NR_SVR4 + 214)
-#define __NR_SVR4_MIPS_reserved7	(__NR_SVR4 + 215)
-#define __NR_SVR4_MIPS_reserved8	(__NR_SVR4 + 216)
-#define __NR_SVR4_MIPS_reserved9	(__NR_SVR4 + 217)
-#define __NR_SVR4_MIPS_reserved10	(__NR_SVR4 + 218)
-#define __NR_SVR4_MIPS_reserved11	(__NR_SVR4 + 219)
-#define __NR_SVR4_MIPS_reserved12	(__NR_SVR4 + 220)
-#define __NR_SVR4_CDC_reserved1		(__NR_SVR4 + 221)
-#define __NR_SVR4_CDC_reserved2		(__NR_SVR4 + 222)
-#define __NR_SVR4_CDC_reserved3		(__NR_SVR4 + 223)
-#define __NR_SVR4_CDC_reserved4		(__NR_SVR4 + 224)
-#define __NR_SVR4_CDC_reserved5		(__NR_SVR4 + 225)
-#define __NR_SVR4_CDC_reserved6		(__NR_SVR4 + 226)
-#define __NR_SVR4_CDC_reserved7		(__NR_SVR4 + 227)
-#define __NR_SVR4_CDC_reserved8		(__NR_SVR4 + 228)
-#define __NR_SVR4_CDC_reserved9		(__NR_SVR4 + 229)
-#define __NR_SVR4_CDC_reserved10	(__NR_SVR4 + 230)
-#define __NR_SVR4_CDC_reserved11	(__NR_SVR4 + 231)
-#define __NR_SVR4_CDC_reserved12	(__NR_SVR4 + 232)
-#define __NR_SVR4_CDC_reserved13	(__NR_SVR4 + 233)
-#define __NR_SVR4_CDC_reserved14	(__NR_SVR4 + 234)
-#define __NR_SVR4_CDC_reserved15	(__NR_SVR4 + 235)
-#define __NR_SVR4_CDC_reserved16	(__NR_SVR4 + 236)
-#define __NR_SVR4_CDC_reserved17	(__NR_SVR4 + 237)
-#define __NR_SVR4_CDC_reserved18	(__NR_SVR4 + 238)
-#define __NR_SVR4_CDC_reserved19	(__NR_SVR4 + 239)
-#define __NR_SVR4_CDC_reserved20	(__NR_SVR4 + 240)
-
-/*
- * SYS V syscalls are in the range from 1000 to 1999
- */
-#define __NR_SYSV			1000
-#define __NR_SYSV_syscall		(__NR_SYSV +   0)
-#define __NR_SYSV_exit			(__NR_SYSV +   1)
-#define __NR_SYSV_fork			(__NR_SYSV +   2)
-#define __NR_SYSV_read			(__NR_SYSV +   3)
-#define __NR_SYSV_write			(__NR_SYSV +   4)
-#define __NR_SYSV_open			(__NR_SYSV +   5)
-#define __NR_SYSV_close			(__NR_SYSV +   6)
-#define __NR_SYSV_wait			(__NR_SYSV +   7)
-#define __NR_SYSV_creat			(__NR_SYSV +   8)
-#define __NR_SYSV_link			(__NR_SYSV +   9)
-#define __NR_SYSV_unlink		(__NR_SYSV +  10)
-#define __NR_SYSV_execv			(__NR_SYSV +  11)
-#define __NR_SYSV_chdir			(__NR_SYSV +  12)
-#define __NR_SYSV_time			(__NR_SYSV +  13)
-#define __NR_SYSV_mknod			(__NR_SYSV +  14)
-#define __NR_SYSV_chmod			(__NR_SYSV +  15)
-#define __NR_SYSV_chown			(__NR_SYSV +  16)
-#define __NR_SYSV_brk			(__NR_SYSV +  17)
-#define __NR_SYSV_stat			(__NR_SYSV +  18)
-#define __NR_SYSV_lseek			(__NR_SYSV +  19)
-#define __NR_SYSV_getpid		(__NR_SYSV +  20)
-#define __NR_SYSV_mount			(__NR_SYSV +  21)
-#define __NR_SYSV_umount		(__NR_SYSV +  22)
-#define __NR_SYSV_setuid		(__NR_SYSV +  23)
-#define __NR_SYSV_getuid		(__NR_SYSV +  24)
-#define __NR_SYSV_stime			(__NR_SYSV +  25)
-#define __NR_SYSV_ptrace		(__NR_SYSV +  26)
-#define __NR_SYSV_alarm			(__NR_SYSV +  27)
-#define __NR_SYSV_fstat			(__NR_SYSV +  28)
-#define __NR_SYSV_pause			(__NR_SYSV +  29)
-#define __NR_SYSV_utime			(__NR_SYSV +  30)
-#define __NR_SYSV_stty			(__NR_SYSV +  31)
-#define __NR_SYSV_gtty			(__NR_SYSV +  32)
-#define __NR_SYSV_access		(__NR_SYSV +  33)
-#define __NR_SYSV_nice			(__NR_SYSV +  34)
-#define __NR_SYSV_statfs		(__NR_SYSV +  35)
-#define __NR_SYSV_sync			(__NR_SYSV +  36)
-#define __NR_SYSV_kill			(__NR_SYSV +  37)
-#define __NR_SYSV_fstatfs		(__NR_SYSV +  38)
-#define __NR_SYSV_setpgrp		(__NR_SYSV +  39)
-#define __NR_SYSV_syssgi		(__NR_SYSV +  40)
-#define __NR_SYSV_dup			(__NR_SYSV +  41)
-#define __NR_SYSV_pipe			(__NR_SYSV +  42)
-#define __NR_SYSV_times			(__NR_SYSV +  43)
-#define __NR_SYSV_profil		(__NR_SYSV +  44)
-#define __NR_SYSV_plock			(__NR_SYSV +  45)
-#define __NR_SYSV_setgid		(__NR_SYSV +  46)
-#define __NR_SYSV_getgid		(__NR_SYSV +  47)
-#define __NR_SYSV_sig			(__NR_SYSV +  48)
-#define __NR_SYSV_msgsys		(__NR_SYSV +  49)
-#define __NR_SYSV_sysmips		(__NR_SYSV +  50)
-#define __NR_SYSV_acct			(__NR_SYSV +  51)
-#define __NR_SYSV_shmsys		(__NR_SYSV +  52)
-#define __NR_SYSV_semsys		(__NR_SYSV +  53)
-#define __NR_SYSV_ioctl			(__NR_SYSV +  54)
-#define __NR_SYSV_uadmin		(__NR_SYSV +  55)
-#define __NR_SYSV_sysmp			(__NR_SYSV +  56)
-#define __NR_SYSV_utssys		(__NR_SYSV +  57)
-#define __NR_SYSV_USG_reserved1		(__NR_SYSV +  58)
-#define __NR_SYSV_execve		(__NR_SYSV +  59)
-#define __NR_SYSV_umask			(__NR_SYSV +  60)
-#define __NR_SYSV_chroot		(__NR_SYSV +  61)
-#define __NR_SYSV_fcntl			(__NR_SYSV +  62)
-#define __NR_SYSV_ulimit		(__NR_SYSV +  63)
-#define __NR_SYSV_SAFARI4_reserved1	(__NR_SYSV +  64)
-#define __NR_SYSV_SAFARI4_reserved2	(__NR_SYSV +  65)
-#define __NR_SYSV_SAFARI4_reserved3	(__NR_SYSV +  66)
-#define __NR_SYSV_SAFARI4_reserved4	(__NR_SYSV +  67)
-#define __NR_SYSV_SAFARI4_reserved5	(__NR_SYSV +  68)
-#define __NR_SYSV_SAFARI4_reserved6	(__NR_SYSV +  69)
-#define __NR_SYSV_advfs			(__NR_SYSV +  70)
-#define __NR_SYSV_unadvfs		(__NR_SYSV +  71)
-#define __NR_SYSV_rmount		(__NR_SYSV +  72)
-#define __NR_SYSV_rumount		(__NR_SYSV +  73)
-#define __NR_SYSV_rfstart		(__NR_SYSV +  74)
-#define __NR_SYSV_getrlimit64		(__NR_SYSV +  75)
-#define __NR_SYSV_setrlimit64		(__NR_SYSV +  76)
-#define __NR_SYSV_nanosleep		(__NR_SYSV +  77)
-#define __NR_SYSV_lseek64		(__NR_SYSV +  78)
-#define __NR_SYSV_rmdir			(__NR_SYSV +  79)
-#define __NR_SYSV_mkdir			(__NR_SYSV +  80)
-#define __NR_SYSV_getdents		(__NR_SYSV +  81)
-#define __NR_SYSV_sginap		(__NR_SYSV +  82)
-#define __NR_SYSV_sgikopt		(__NR_SYSV +  83)
-#define __NR_SYSV_sysfs			(__NR_SYSV +  84)
-#define __NR_SYSV_getmsg		(__NR_SYSV +  85)
-#define __NR_SYSV_putmsg		(__NR_SYSV +  86)
-#define __NR_SYSV_poll			(__NR_SYSV +  87)
-#define __NR_SYSV_sigreturn		(__NR_SYSV +  88)
-#define __NR_SYSV_accept		(__NR_SYSV +  89)
-#define __NR_SYSV_bind			(__NR_SYSV +  90)
-#define __NR_SYSV_connect		(__NR_SYSV +  91)
-#define __NR_SYSV_gethostid		(__NR_SYSV +  92)
-#define __NR_SYSV_getpeername		(__NR_SYSV +  93)
-#define __NR_SYSV_getsockname		(__NR_SYSV +  94)
-#define __NR_SYSV_getsockopt		(__NR_SYSV +  95)
-#define __NR_SYSV_listen		(__NR_SYSV +  96)
-#define __NR_SYSV_recv			(__NR_SYSV +  97)
-#define __NR_SYSV_recvfrom		(__NR_SYSV +  98)
-#define __NR_SYSV_recvmsg		(__NR_SYSV +  99)
-#define __NR_SYSV_select		(__NR_SYSV + 100)
-#define __NR_SYSV_send			(__NR_SYSV + 101)
-#define __NR_SYSV_sendmsg		(__NR_SYSV + 102)
-#define __NR_SYSV_sendto		(__NR_SYSV + 103)
-#define __NR_SYSV_sethostid		(__NR_SYSV + 104)
-#define __NR_SYSV_setsockopt		(__NR_SYSV + 105)
-#define __NR_SYSV_shutdown		(__NR_SYSV + 106)
-#define __NR_SYSV_socket		(__NR_SYSV + 107)
-#define __NR_SYSV_gethostname		(__NR_SYSV + 108)
-#define __NR_SYSV_sethostname		(__NR_SYSV + 109)
-#define __NR_SYSV_getdomainname		(__NR_SYSV + 110)
-#define __NR_SYSV_setdomainname		(__NR_SYSV + 111)
-#define __NR_SYSV_truncate		(__NR_SYSV + 112)
-#define __NR_SYSV_ftruncate		(__NR_SYSV + 113)
-#define __NR_SYSV_rename		(__NR_SYSV + 114)
-#define __NR_SYSV_symlink		(__NR_SYSV + 115)
-#define __NR_SYSV_readlink		(__NR_SYSV + 116)
-#define __NR_SYSV_lstat			(__NR_SYSV + 117)
-#define __NR_SYSV_nfsmount		(__NR_SYSV + 118)
-#define __NR_SYSV_nfssvc		(__NR_SYSV + 119)
-#define __NR_SYSV_getfh			(__NR_SYSV + 120)
-#define __NR_SYSV_async_daemon		(__NR_SYSV + 121)
-#define __NR_SYSV_exportfs		(__NR_SYSV + 122)
-#define __NR_SYSV_setregid		(__NR_SYSV + 123)
-#define __NR_SYSV_setreuid		(__NR_SYSV + 124)
-#define __NR_SYSV_getitimer		(__NR_SYSV + 125)
-#define __NR_SYSV_setitimer		(__NR_SYSV + 126)
-#define __NR_SYSV_adjtime		(__NR_SYSV + 127)
-#define __NR_SYSV_BSD_getime		(__NR_SYSV + 128)
-#define __NR_SYSV_sproc			(__NR_SYSV + 129)
-#define __NR_SYSV_prctl			(__NR_SYSV + 130)
-#define __NR_SYSV_procblk		(__NR_SYSV + 131)
-#define __NR_SYSV_sprocsp		(__NR_SYSV + 132)
-#define __NR_SYSV_sgigsc		(__NR_SYSV + 133)
-#define __NR_SYSV_mmap			(__NR_SYSV + 134)
-#define __NR_SYSV_munmap		(__NR_SYSV + 135)
-#define __NR_SYSV_mprotect		(__NR_SYSV + 136)
-#define __NR_SYSV_msync			(__NR_SYSV + 137)
-#define __NR_SYSV_madvise		(__NR_SYSV + 138)
-#define __NR_SYSV_pagelock		(__NR_SYSV + 139)
-#define __NR_SYSV_getpagesize		(__NR_SYSV + 140)
-#define __NR_SYSV_quotactl		(__NR_SYSV + 141)
-#define __NR_SYSV_libdetach		(__NR_SYSV + 142)
-#define __NR_SYSV_BSDgetpgrp		(__NR_SYSV + 143)
-#define __NR_SYSV_BSDsetpgrp		(__NR_SYSV + 144)
-#define __NR_SYSV_vhangup		(__NR_SYSV + 145)
-#define __NR_SYSV_fsync			(__NR_SYSV + 146)
-#define __NR_SYSV_fchdir		(__NR_SYSV + 147)
-#define __NR_SYSV_getrlimit		(__NR_SYSV + 148)
-#define __NR_SYSV_setrlimit		(__NR_SYSV + 149)
-#define __NR_SYSV_cacheflush		(__NR_SYSV + 150)
-#define __NR_SYSV_cachectl		(__NR_SYSV + 151)
-#define __NR_SYSV_fchown		(__NR_SYSV + 152)
-#define __NR_SYSV_fchmod		(__NR_SYSV + 153)
-#define __NR_SYSV_wait3			(__NR_SYSV + 154)
-#define __NR_SYSV_socketpair		(__NR_SYSV + 155)
-#define __NR_SYSV_sysinfo		(__NR_SYSV + 156)
-#define __NR_SYSV_nuname		(__NR_SYSV + 157)
-#define __NR_SYSV_xstat			(__NR_SYSV + 158)
-#define __NR_SYSV_lxstat		(__NR_SYSV + 159)
-#define __NR_SYSV_fxstat		(__NR_SYSV + 160)
-#define __NR_SYSV_xmknod		(__NR_SYSV + 161)
-#define __NR_SYSV_ksigaction		(__NR_SYSV + 162)
-#define __NR_SYSV_sigpending		(__NR_SYSV + 163)
-#define __NR_SYSV_sigprocmask		(__NR_SYSV + 164)
-#define __NR_SYSV_sigsuspend		(__NR_SYSV + 165)
-#define __NR_SYSV_sigpoll		(__NR_SYSV + 166)
-#define __NR_SYSV_swapctl		(__NR_SYSV + 167)
-#define __NR_SYSV_getcontext		(__NR_SYSV + 168)
-#define __NR_SYSV_setcontext		(__NR_SYSV + 169)
-#define __NR_SYSV_waitsys		(__NR_SYSV + 170)
-#define __NR_SYSV_sigstack		(__NR_SYSV + 171)
-#define __NR_SYSV_sigaltstack		(__NR_SYSV + 172)
-#define __NR_SYSV_sigsendset		(__NR_SYSV + 173)
-#define __NR_SYSV_statvfs		(__NR_SYSV + 174)
-#define __NR_SYSV_fstatvfs		(__NR_SYSV + 175)
-#define __NR_SYSV_getpmsg		(__NR_SYSV + 176)
-#define __NR_SYSV_putpmsg		(__NR_SYSV + 177)
-#define __NR_SYSV_lchown		(__NR_SYSV + 178)
-#define __NR_SYSV_priocntl		(__NR_SYSV + 179)
-#define __NR_SYSV_ksigqueue		(__NR_SYSV + 180)
-#define __NR_SYSV_readv			(__NR_SYSV + 181)
-#define __NR_SYSV_writev		(__NR_SYSV + 182)
-#define __NR_SYSV_truncate64		(__NR_SYSV + 183)
-#define __NR_SYSV_ftruncate64		(__NR_SYSV + 184)
-#define __NR_SYSV_mmap64		(__NR_SYSV + 185)
-#define __NR_SYSV_dmi			(__NR_SYSV + 186)
-#define __NR_SYSV_pread			(__NR_SYSV + 187)
-#define __NR_SYSV_pwrite		(__NR_SYSV + 188)
-
-/*
- * BSD 4.3 syscalls are in the range from 2000 to 2999
- */
-#define __NR_BSD43			2000
-#define __NR_BSD43_syscall		(__NR_BSD43 +   0)
-#define __NR_BSD43_exit			(__NR_BSD43 +   1)
-#define __NR_BSD43_fork			(__NR_BSD43 +   2)
-#define __NR_BSD43_read			(__NR_BSD43 +   3)
-#define __NR_BSD43_write		(__NR_BSD43 +   4)
-#define __NR_BSD43_open			(__NR_BSD43 +   5)
-#define __NR_BSD43_close		(__NR_BSD43 +   6)
-#define __NR_BSD43_wait			(__NR_BSD43 +   7)
-#define __NR_BSD43_creat		(__NR_BSD43 +   8)
-#define __NR_BSD43_link			(__NR_BSD43 +   9)
-#define __NR_BSD43_unlink		(__NR_BSD43 +  10)
-#define __NR_BSD43_exec			(__NR_BSD43 +  11)
-#define __NR_BSD43_chdir		(__NR_BSD43 +  12)
-#define __NR_BSD43_time			(__NR_BSD43 +  13)
-#define __NR_BSD43_mknod		(__NR_BSD43 +  14)
-#define __NR_BSD43_chmod		(__NR_BSD43 +  15)
-#define __NR_BSD43_chown		(__NR_BSD43 +  16)
-#define __NR_BSD43_sbreak		(__NR_BSD43 +  17)
-#define __NR_BSD43_oldstat		(__NR_BSD43 +  18)
-#define __NR_BSD43_lseek		(__NR_BSD43 +  19)
-#define __NR_BSD43_getpid		(__NR_BSD43 +  20)
-#define __NR_BSD43_oldmount		(__NR_BSD43 +  21)
-#define __NR_BSD43_umount		(__NR_BSD43 +  22)
-#define __NR_BSD43_setuid		(__NR_BSD43 +  23)
-#define __NR_BSD43_getuid		(__NR_BSD43 +  24)
-#define __NR_BSD43_stime		(__NR_BSD43 +  25)
-#define __NR_BSD43_ptrace		(__NR_BSD43 +  26)
-#define __NR_BSD43_alarm		(__NR_BSD43 +  27)
-#define __NR_BSD43_oldfstat		(__NR_BSD43 +  28)
-#define __NR_BSD43_pause		(__NR_BSD43 +  29)
-#define __NR_BSD43_utime		(__NR_BSD43 +  30)
-#define __NR_BSD43_stty			(__NR_BSD43 +  31)
-#define __NR_BSD43_gtty			(__NR_BSD43 +  32)
-#define __NR_BSD43_access		(__NR_BSD43 +  33)
-#define __NR_BSD43_nice			(__NR_BSD43 +  34)
-#define __NR_BSD43_ftime		(__NR_BSD43 +  35)
-#define __NR_BSD43_sync			(__NR_BSD43 +  36)
-#define __NR_BSD43_kill			(__NR_BSD43 +  37)
-#define __NR_BSD43_stat			(__NR_BSD43 +  38)
-#define __NR_BSD43_oldsetpgrp		(__NR_BSD43 +  39)
-#define __NR_BSD43_lstat		(__NR_BSD43 +  40)
-#define __NR_BSD43_dup			(__NR_BSD43 +  41)
-#define __NR_BSD43_pipe			(__NR_BSD43 +  42)
-#define __NR_BSD43_times		(__NR_BSD43 +  43)
-#define __NR_BSD43_profil		(__NR_BSD43 +  44)
-#define __NR_BSD43_msgsys		(__NR_BSD43 +  45)
-#define __NR_BSD43_setgid		(__NR_BSD43 +  46)
-#define __NR_BSD43_getgid		(__NR_BSD43 +  47)
-#define __NR_BSD43_ssig			(__NR_BSD43 +  48)
-#define __NR_BSD43_reserved1		(__NR_BSD43 +  49)
-#define __NR_BSD43_reserved2		(__NR_BSD43 +  50)
-#define __NR_BSD43_sysacct		(__NR_BSD43 +  51)
-#define __NR_BSD43_phys			(__NR_BSD43 +  52)
-#define __NR_BSD43_lock			(__NR_BSD43 +  53)
-#define __NR_BSD43_ioctl		(__NR_BSD43 +  54)
-#define __NR_BSD43_reboot		(__NR_BSD43 +  55)
-#define __NR_BSD43_mpxchan		(__NR_BSD43 +  56)
-#define __NR_BSD43_symlink		(__NR_BSD43 +  57)
-#define __NR_BSD43_readlink		(__NR_BSD43 +  58)
-#define __NR_BSD43_execve		(__NR_BSD43 +  59)
-#define __NR_BSD43_umask		(__NR_BSD43 +  60)
-#define __NR_BSD43_chroot		(__NR_BSD43 +  61)
-#define __NR_BSD43_fstat		(__NR_BSD43 +  62)
-#define __NR_BSD43_reserved3		(__NR_BSD43 +  63)
-#define __NR_BSD43_getpagesize		(__NR_BSD43 +  64)
-#define __NR_BSD43_mremap		(__NR_BSD43 +  65)
-#define __NR_BSD43_vfork		(__NR_BSD43 +  66)
-#define __NR_BSD43_vread		(__NR_BSD43 +  67)
-#define __NR_BSD43_vwrite		(__NR_BSD43 +  68)
-#define __NR_BSD43_sbrk			(__NR_BSD43 +  69)
-#define __NR_BSD43_sstk			(__NR_BSD43 +  70)
-#define __NR_BSD43_mmap			(__NR_BSD43 +  71)
-#define __NR_BSD43_vadvise		(__NR_BSD43 +  72)
-#define __NR_BSD43_munmap		(__NR_BSD43 +  73)
-#define __NR_BSD43_mprotect		(__NR_BSD43 +  74)
-#define __NR_BSD43_madvise		(__NR_BSD43 +  75)
-#define __NR_BSD43_vhangup		(__NR_BSD43 +  76)
-#define __NR_BSD43_vlimit		(__NR_BSD43 +  77)
-#define __NR_BSD43_mincore		(__NR_BSD43 +  78)
-#define __NR_BSD43_getgroups		(__NR_BSD43 +  79)
-#define __NR_BSD43_setgroups		(__NR_BSD43 +  80)
-#define __NR_BSD43_getpgrp		(__NR_BSD43 +  81)
-#define __NR_BSD43_setpgrp		(__NR_BSD43 +  82)
-#define __NR_BSD43_setitimer		(__NR_BSD43 +  83)
-#define __NR_BSD43_wait3		(__NR_BSD43 +  84)
-#define __NR_BSD43_swapon		(__NR_BSD43 +  85)
-#define __NR_BSD43_getitimer		(__NR_BSD43 +  86)
-#define __NR_BSD43_gethostname		(__NR_BSD43 +  87)
-#define __NR_BSD43_sethostname		(__NR_BSD43 +  88)
-#define __NR_BSD43_getdtablesize	(__NR_BSD43 +  89)
-#define __NR_BSD43_dup2			(__NR_BSD43 +  90)
-#define __NR_BSD43_getdopt		(__NR_BSD43 +  91)
-#define __NR_BSD43_fcntl		(__NR_BSD43 +  92)
-#define __NR_BSD43_select		(__NR_BSD43 +  93)
-#define __NR_BSD43_setdopt		(__NR_BSD43 +  94)
-#define __NR_BSD43_fsync		(__NR_BSD43 +  95)
-#define __NR_BSD43_setpriority		(__NR_BSD43 +  96)
-#define __NR_BSD43_socket		(__NR_BSD43 +  97)
-#define __NR_BSD43_connect		(__NR_BSD43 +  98)
-#define __NR_BSD43_oldaccept		(__NR_BSD43 +  99)
-#define __NR_BSD43_getpriority		(__NR_BSD43 + 100)
-#define __NR_BSD43_send			(__NR_BSD43 + 101)
-#define __NR_BSD43_recv			(__NR_BSD43 + 102)
-#define __NR_BSD43_sigreturn		(__NR_BSD43 + 103)
-#define __NR_BSD43_bind			(__NR_BSD43 + 104)
-#define __NR_BSD43_setsockopt		(__NR_BSD43 + 105)
-#define __NR_BSD43_listen		(__NR_BSD43 + 106)
-#define __NR_BSD43_vtimes		(__NR_BSD43 + 107)
-#define __NR_BSD43_sigvec		(__NR_BSD43 + 108)
-#define __NR_BSD43_sigblock		(__NR_BSD43 + 109)
-#define __NR_BSD43_sigsetmask		(__NR_BSD43 + 110)
-#define __NR_BSD43_sigpause		(__NR_BSD43 + 111)
-#define __NR_BSD43_sigstack		(__NR_BSD43 + 112)
-#define __NR_BSD43_oldrecvmsg		(__NR_BSD43 + 113)
-#define __NR_BSD43_oldsendmsg		(__NR_BSD43 + 114)
-#define __NR_BSD43_vtrace		(__NR_BSD43 + 115)
-#define __NR_BSD43_gettimeofday		(__NR_BSD43 + 116)
-#define __NR_BSD43_getrusage		(__NR_BSD43 + 117)
-#define __NR_BSD43_getsockopt		(__NR_BSD43 + 118)
-#define __NR_BSD43_reserved4		(__NR_BSD43 + 119)
-#define __NR_BSD43_readv		(__NR_BSD43 + 120)
-#define __NR_BSD43_writev		(__NR_BSD43 + 121)
-#define __NR_BSD43_settimeofday		(__NR_BSD43 + 122)
-#define __NR_BSD43_fchown		(__NR_BSD43 + 123)
-#define __NR_BSD43_fchmod		(__NR_BSD43 + 124)
-#define __NR_BSD43_oldrecvfrom		(__NR_BSD43 + 125)
-#define __NR_BSD43_setreuid		(__NR_BSD43 + 126)
-#define __NR_BSD43_setregid		(__NR_BSD43 + 127)
-#define __NR_BSD43_rename		(__NR_BSD43 + 128)
-#define __NR_BSD43_truncate		(__NR_BSD43 + 129)
-#define __NR_BSD43_ftruncate		(__NR_BSD43 + 130)
-#define __NR_BSD43_flock		(__NR_BSD43 + 131)
-#define __NR_BSD43_semsys		(__NR_BSD43 + 132)
-#define __NR_BSD43_sendto		(__NR_BSD43 + 133)
-#define __NR_BSD43_shutdown		(__NR_BSD43 + 134)
-#define __NR_BSD43_socketpair		(__NR_BSD43 + 135)
-#define __NR_BSD43_mkdir		(__NR_BSD43 + 136)
-#define __NR_BSD43_rmdir		(__NR_BSD43 + 137)
-#define __NR_BSD43_utimes		(__NR_BSD43 + 138)
-#define __NR_BSD43_sigcleanup		(__NR_BSD43 + 139)
-#define __NR_BSD43_adjtime		(__NR_BSD43 + 140)
-#define __NR_BSD43_oldgetpeername	(__NR_BSD43 + 141)
-#define __NR_BSD43_gethostid		(__NR_BSD43 + 142)
-#define __NR_BSD43_sethostid		(__NR_BSD43 + 143)
-#define __NR_BSD43_getrlimit		(__NR_BSD43 + 144)
-#define __NR_BSD43_setrlimit		(__NR_BSD43 + 145)
-#define __NR_BSD43_killpg		(__NR_BSD43 + 146)
-#define __NR_BSD43_shmsys		(__NR_BSD43 + 147)
-#define __NR_BSD43_quota		(__NR_BSD43 + 148)
-#define __NR_BSD43_qquota		(__NR_BSD43 + 149)
-#define __NR_BSD43_oldgetsockname	(__NR_BSD43 + 150)
-#define __NR_BSD43_sysmips		(__NR_BSD43 + 151)
-#define __NR_BSD43_cacheflush		(__NR_BSD43 + 152)
-#define __NR_BSD43_cachectl		(__NR_BSD43 + 153)
-#define __NR_BSD43_debug		(__NR_BSD43 + 154)
-#define __NR_BSD43_reserved5		(__NR_BSD43 + 155)
-#define __NR_BSD43_reserved6		(__NR_BSD43 + 156)
-#define __NR_BSD43_nfs_mount		(__NR_BSD43 + 157)
-#define __NR_BSD43_nfs_svc		(__NR_BSD43 + 158)
-#define __NR_BSD43_getdirentries	(__NR_BSD43 + 159)
-#define __NR_BSD43_statfs		(__NR_BSD43 + 160)
-#define __NR_BSD43_fstatfs		(__NR_BSD43 + 161)
-#define __NR_BSD43_unmount		(__NR_BSD43 + 162)
-#define __NR_BSD43_async_daemon		(__NR_BSD43 + 163)
-#define __NR_BSD43_nfs_getfh		(__NR_BSD43 + 164)
-#define __NR_BSD43_getdomainname	(__NR_BSD43 + 165)
-#define __NR_BSD43_setdomainname	(__NR_BSD43 + 166)
-#define __NR_BSD43_pcfs_mount		(__NR_BSD43 + 167)
-#define __NR_BSD43_quotactl		(__NR_BSD43 + 168)
-#define __NR_BSD43_oldexportfs		(__NR_BSD43 + 169)
-#define __NR_BSD43_smount		(__NR_BSD43 + 170)
-#define __NR_BSD43_mipshwconf		(__NR_BSD43 + 171)
-#define __NR_BSD43_exportfs		(__NR_BSD43 + 172)
-#define __NR_BSD43_nfsfh_open		(__NR_BSD43 + 173)
-#define __NR_BSD43_libattach		(__NR_BSD43 + 174)
-#define __NR_BSD43_libdetach		(__NR_BSD43 + 175)
-#define __NR_BSD43_accept		(__NR_BSD43 + 176)
-#define __NR_BSD43_reserved7		(__NR_BSD43 + 177)
-#define __NR_BSD43_reserved8		(__NR_BSD43 + 178)
-#define __NR_BSD43_recvmsg		(__NR_BSD43 + 179)
-#define __NR_BSD43_recvfrom		(__NR_BSD43 + 180)
-#define __NR_BSD43_sendmsg		(__NR_BSD43 + 181)
-#define __NR_BSD43_getpeername		(__NR_BSD43 + 182)
-#define __NR_BSD43_getsockname		(__NR_BSD43 + 183)
-#define __NR_BSD43_aread		(__NR_BSD43 + 184)
-#define __NR_BSD43_awrite		(__NR_BSD43 + 185)
-#define __NR_BSD43_listio		(__NR_BSD43 + 186)
-#define __NR_BSD43_acancel		(__NR_BSD43 + 187)
-#define __NR_BSD43_astatus		(__NR_BSD43 + 188)
-#define __NR_BSD43_await		(__NR_BSD43 + 189)
-#define __NR_BSD43_areadv		(__NR_BSD43 + 190)
-#define __NR_BSD43_awritev		(__NR_BSD43 + 191)
-
-/*
- * POSIX syscalls are in the range from 3000 to 3999
- */
-#define __NR_POSIX			3000
-#define __NR_POSIX_syscall		(__NR_POSIX +   0)
-#define __NR_POSIX_exit			(__NR_POSIX +   1)
-#define __NR_POSIX_fork			(__NR_POSIX +   2)
-#define __NR_POSIX_read			(__NR_POSIX +   3)
-#define __NR_POSIX_write		(__NR_POSIX +   4)
-#define __NR_POSIX_open			(__NR_POSIX +   5)
-#define __NR_POSIX_close		(__NR_POSIX +   6)
-#define __NR_POSIX_wait			(__NR_POSIX +   7)
-#define __NR_POSIX_creat		(__NR_POSIX +   8)
-#define __NR_POSIX_link			(__NR_POSIX +   9)
-#define __NR_POSIX_unlink		(__NR_POSIX +  10)
-#define __NR_POSIX_exec			(__NR_POSIX +  11)
-#define __NR_POSIX_chdir		(__NR_POSIX +  12)
-#define __NR_POSIX_gtime		(__NR_POSIX +  13)
-#define __NR_POSIX_mknod		(__NR_POSIX +  14)
-#define __NR_POSIX_chmod		(__NR_POSIX +  15)
-#define __NR_POSIX_chown		(__NR_POSIX +  16)
-#define __NR_POSIX_sbreak		(__NR_POSIX +  17)
-#define __NR_POSIX_stat			(__NR_POSIX +  18)
-#define __NR_POSIX_lseek		(__NR_POSIX +  19)
-#define __NR_POSIX_getpid		(__NR_POSIX +  20)
-#define __NR_POSIX_mount		(__NR_POSIX +  21)
-#define __NR_POSIX_umount		(__NR_POSIX +  22)
-#define __NR_POSIX_setuid		(__NR_POSIX +  23)
-#define __NR_POSIX_getuid		(__NR_POSIX +  24)
-#define __NR_POSIX_stime		(__NR_POSIX +  25)
-#define __NR_POSIX_ptrace		(__NR_POSIX +  26)
-#define __NR_POSIX_alarm		(__NR_POSIX +  27)
-#define __NR_POSIX_fstat		(__NR_POSIX +  28)
-#define __NR_POSIX_pause		(__NR_POSIX +  29)
-#define __NR_POSIX_utime		(__NR_POSIX +  30)
-#define __NR_POSIX_stty			(__NR_POSIX +  31)
-#define __NR_POSIX_gtty			(__NR_POSIX +  32)
-#define __NR_POSIX_access		(__NR_POSIX +  33)
-#define __NR_POSIX_nice			(__NR_POSIX +  34)
-#define __NR_POSIX_statfs		(__NR_POSIX +  35)
-#define __NR_POSIX_sync			(__NR_POSIX +  36)
-#define __NR_POSIX_kill			(__NR_POSIX +  37)
-#define __NR_POSIX_fstatfs		(__NR_POSIX +  38)
-#define __NR_POSIX_getpgrp		(__NR_POSIX +  39)
-#define __NR_POSIX_syssgi		(__NR_POSIX +  40)
-#define __NR_POSIX_dup			(__NR_POSIX +  41)
-#define __NR_POSIX_pipe			(__NR_POSIX +  42)
-#define __NR_POSIX_times		(__NR_POSIX +  43)
-#define __NR_POSIX_profil		(__NR_POSIX +  44)
-#define __NR_POSIX_lock			(__NR_POSIX +  45)
-#define __NR_POSIX_setgid		(__NR_POSIX +  46)
-#define __NR_POSIX_getgid		(__NR_POSIX +  47)
-#define __NR_POSIX_sig			(__NR_POSIX +  48)
-#define __NR_POSIX_msgsys		(__NR_POSIX +  49)
-#define __NR_POSIX_sysmips		(__NR_POSIX +  50)
-#define __NR_POSIX_sysacct		(__NR_POSIX +  51)
-#define __NR_POSIX_shmsys		(__NR_POSIX +  52)
-#define __NR_POSIX_semsys		(__NR_POSIX +  53)
-#define __NR_POSIX_ioctl		(__NR_POSIX +  54)
-#define __NR_POSIX_uadmin		(__NR_POSIX +  55)
-#define __NR_POSIX_exch			(__NR_POSIX +  56)
-#define __NR_POSIX_utssys		(__NR_POSIX +  57)
-#define __NR_POSIX_USG_reserved1	(__NR_POSIX +  58)
-#define __NR_POSIX_exece		(__NR_POSIX +  59)
-#define __NR_POSIX_umask		(__NR_POSIX +  60)
-#define __NR_POSIX_chroot		(__NR_POSIX +  61)
-#define __NR_POSIX_fcntl		(__NR_POSIX +  62)
-#define __NR_POSIX_ulimit		(__NR_POSIX +  63)
-#define __NR_POSIX_SAFARI4_reserved1	(__NR_POSIX +  64)
-#define __NR_POSIX_SAFARI4_reserved2	(__NR_POSIX +  65)
-#define __NR_POSIX_SAFARI4_reserved3	(__NR_POSIX +  66)
-#define __NR_POSIX_SAFARI4_reserved4	(__NR_POSIX +  67)
-#define __NR_POSIX_SAFARI4_reserved5	(__NR_POSIX +  68)
-#define __NR_POSIX_SAFARI4_reserved6	(__NR_POSIX +  69)
-#define __NR_POSIX_advfs		(__NR_POSIX +  70)
-#define __NR_POSIX_unadvfs		(__NR_POSIX +  71)
-#define __NR_POSIX_rmount		(__NR_POSIX +  72)
-#define __NR_POSIX_rumount		(__NR_POSIX +  73)
-#define __NR_POSIX_rfstart		(__NR_POSIX +  74)
-#define __NR_POSIX_reserved1		(__NR_POSIX +  75)
-#define __NR_POSIX_rdebug		(__NR_POSIX +  76)
-#define __NR_POSIX_rfstop		(__NR_POSIX +  77)
-#define __NR_POSIX_rfsys		(__NR_POSIX +  78)
-#define __NR_POSIX_rmdir		(__NR_POSIX +  79)
-#define __NR_POSIX_mkdir		(__NR_POSIX +  80)
-#define __NR_POSIX_getdents		(__NR_POSIX +  81)
-#define __NR_POSIX_sginap		(__NR_POSIX +  82)
-#define __NR_POSIX_sgikopt		(__NR_POSIX +  83)
-#define __NR_POSIX_sysfs		(__NR_POSIX +  84)
-#define __NR_POSIX_getmsg		(__NR_POSIX +  85)
-#define __NR_POSIX_putmsg		(__NR_POSIX +  86)
-#define __NR_POSIX_poll			(__NR_POSIX +  87)
-#define __NR_POSIX_sigreturn		(__NR_POSIX +  88)
-#define __NR_POSIX_accept		(__NR_POSIX +  89)
-#define __NR_POSIX_bind			(__NR_POSIX +  90)
-#define __NR_POSIX_connect		(__NR_POSIX +  91)
-#define __NR_POSIX_gethostid		(__NR_POSIX +  92)
-#define __NR_POSIX_getpeername		(__NR_POSIX +  93)
-#define __NR_POSIX_getsockname		(__NR_POSIX +  94)
-#define __NR_POSIX_getsockopt		(__NR_POSIX +  95)
-#define __NR_POSIX_listen		(__NR_POSIX +  96)
-#define __NR_POSIX_recv			(__NR_POSIX +  97)
-#define __NR_POSIX_recvfrom		(__NR_POSIX +  98)
-#define __NR_POSIX_recvmsg		(__NR_POSIX +  99)
-#define __NR_POSIX_select		(__NR_POSIX + 100)
-#define __NR_POSIX_send			(__NR_POSIX + 101)
-#define __NR_POSIX_sendmsg		(__NR_POSIX + 102)
-#define __NR_POSIX_sendto		(__NR_POSIX + 103)
-#define __NR_POSIX_sethostid		(__NR_POSIX + 104)
-#define __NR_POSIX_setsockopt		(__NR_POSIX + 105)
-#define __NR_POSIX_shutdown		(__NR_POSIX + 106)
-#define __NR_POSIX_socket		(__NR_POSIX + 107)
-#define __NR_POSIX_gethostname		(__NR_POSIX + 108)
-#define __NR_POSIX_sethostname		(__NR_POSIX + 109)
-#define __NR_POSIX_getdomainname	(__NR_POSIX + 110)
-#define __NR_POSIX_setdomainname	(__NR_POSIX + 111)
-#define __NR_POSIX_truncate		(__NR_POSIX + 112)
-#define __NR_POSIX_ftruncate		(__NR_POSIX + 113)
-#define __NR_POSIX_rename		(__NR_POSIX + 114)
-#define __NR_POSIX_symlink		(__NR_POSIX + 115)
-#define __NR_POSIX_readlink		(__NR_POSIX + 116)
-#define __NR_POSIX_lstat		(__NR_POSIX + 117)
-#define __NR_POSIX_nfs_mount		(__NR_POSIX + 118)
-#define __NR_POSIX_nfs_svc		(__NR_POSIX + 119)
-#define __NR_POSIX_nfs_getfh		(__NR_POSIX + 120)
-#define __NR_POSIX_async_daemon		(__NR_POSIX + 121)
-#define __NR_POSIX_exportfs		(__NR_POSIX + 122)
-#define __NR_POSIX_SGI_setregid		(__NR_POSIX + 123)
-#define __NR_POSIX_SGI_setreuid		(__NR_POSIX + 124)
-#define __NR_POSIX_getitimer		(__NR_POSIX + 125)
-#define __NR_POSIX_setitimer		(__NR_POSIX + 126)
-#define __NR_POSIX_adjtime		(__NR_POSIX + 127)
-#define __NR_POSIX_SGI_bsdgettime	(__NR_POSIX + 128)
-#define __NR_POSIX_SGI_sproc		(__NR_POSIX + 129)
-#define __NR_POSIX_SGI_prctl		(__NR_POSIX + 130)
-#define __NR_POSIX_SGI_blkproc		(__NR_POSIX + 131)
-#define __NR_POSIX_SGI_reserved1	(__NR_POSIX + 132)
-#define __NR_POSIX_SGI_sgigsc		(__NR_POSIX + 133)
-#define __NR_POSIX_SGI_mmap		(__NR_POSIX + 134)
-#define __NR_POSIX_SGI_munmap		(__NR_POSIX + 135)
-#define __NR_POSIX_SGI_mprotect		(__NR_POSIX + 136)
-#define __NR_POSIX_SGI_msync		(__NR_POSIX + 137)
-#define __NR_POSIX_SGI_madvise		(__NR_POSIX + 138)
-#define __NR_POSIX_SGI_mpin		(__NR_POSIX + 139)
-#define __NR_POSIX_SGI_getpagesize	(__NR_POSIX + 140)
-#define __NR_POSIX_SGI_libattach	(__NR_POSIX + 141)
-#define __NR_POSIX_SGI_libdetach	(__NR_POSIX + 142)
-#define __NR_POSIX_SGI_getpgrp		(__NR_POSIX + 143)
-#define __NR_POSIX_SGI_setpgrp		(__NR_POSIX + 144)
-#define __NR_POSIX_SGI_reserved2	(__NR_POSIX + 145)
-#define __NR_POSIX_SGI_reserved3	(__NR_POSIX + 146)
-#define __NR_POSIX_SGI_reserved4	(__NR_POSIX + 147)
-#define __NR_POSIX_SGI_reserved5	(__NR_POSIX + 148)
-#define __NR_POSIX_SGI_reserved6	(__NR_POSIX + 149)
-#define __NR_POSIX_cacheflush		(__NR_POSIX + 150)
-#define __NR_POSIX_cachectl		(__NR_POSIX + 151)
-#define __NR_POSIX_fchown		(__NR_POSIX + 152)
-#define __NR_POSIX_fchmod		(__NR_POSIX + 153)
-#define __NR_POSIX_wait3		(__NR_POSIX + 154)
-#define __NR_POSIX_mmap			(__NR_POSIX + 155)
-#define __NR_POSIX_munmap		(__NR_POSIX + 156)
-#define __NR_POSIX_madvise		(__NR_POSIX + 157)
-#define __NR_POSIX_BSD_getpagesize	(__NR_POSIX + 158)
-#define __NR_POSIX_setreuid		(__NR_POSIX + 159)
-#define __NR_POSIX_setregid		(__NR_POSIX + 160)
-#define __NR_POSIX_setpgid		(__NR_POSIX + 161)
-#define __NR_POSIX_getgroups		(__NR_POSIX + 162)
-#define __NR_POSIX_setgroups		(__NR_POSIX + 163)
-#define __NR_POSIX_gettimeofday		(__NR_POSIX + 164)
-#define __NR_POSIX_getrusage		(__NR_POSIX + 165)
-#define __NR_POSIX_getrlimit		(__NR_POSIX + 166)
-#define __NR_POSIX_setrlimit		(__NR_POSIX + 167)
-#define __NR_POSIX_waitpid		(__NR_POSIX + 168)
-#define __NR_POSIX_dup2			(__NR_POSIX + 169)
-#define __NR_POSIX_reserved2		(__NR_POSIX + 170)
-#define __NR_POSIX_reserved3		(__NR_POSIX + 171)
-#define __NR_POSIX_reserved4		(__NR_POSIX + 172)
-#define __NR_POSIX_reserved5		(__NR_POSIX + 173)
-#define __NR_POSIX_reserved6		(__NR_POSIX + 174)
-#define __NR_POSIX_reserved7		(__NR_POSIX + 175)
-#define __NR_POSIX_reserved8		(__NR_POSIX + 176)
-#define __NR_POSIX_reserved9		(__NR_POSIX + 177)
-#define __NR_POSIX_reserved10		(__NR_POSIX + 178)
-#define __NR_POSIX_reserved11		(__NR_POSIX + 179)
-#define __NR_POSIX_reserved12		(__NR_POSIX + 180)
-#define __NR_POSIX_reserved13		(__NR_POSIX + 181)
-#define __NR_POSIX_reserved14		(__NR_POSIX + 182)
-#define __NR_POSIX_reserved15		(__NR_POSIX + 183)
-#define __NR_POSIX_reserved16		(__NR_POSIX + 184)
-#define __NR_POSIX_reserved17		(__NR_POSIX + 185)
-#define __NR_POSIX_reserved18		(__NR_POSIX + 186)
-#define __NR_POSIX_reserved19		(__NR_POSIX + 187)
-#define __NR_POSIX_reserved20		(__NR_POSIX + 188)
-#define __NR_POSIX_reserved21		(__NR_POSIX + 189)
-#define __NR_POSIX_reserved22		(__NR_POSIX + 190)
-#define __NR_POSIX_reserved23		(__NR_POSIX + 191)
-#define __NR_POSIX_reserved24		(__NR_POSIX + 192)
-#define __NR_POSIX_reserved25		(__NR_POSIX + 193)
-#define __NR_POSIX_reserved26		(__NR_POSIX + 194)
-#define __NR_POSIX_reserved27		(__NR_POSIX + 195)
-#define __NR_POSIX_reserved28		(__NR_POSIX + 196)
-#define __NR_POSIX_reserved29		(__NR_POSIX + 197)
-#define __NR_POSIX_reserved30		(__NR_POSIX + 198)
-#define __NR_POSIX_reserved31		(__NR_POSIX + 199)
-#define __NR_POSIX_reserved32		(__NR_POSIX + 200)
-#define __NR_POSIX_reserved33		(__NR_POSIX + 201)
-#define __NR_POSIX_reserved34		(__NR_POSIX + 202)
-#define __NR_POSIX_reserved35		(__NR_POSIX + 203)
-#define __NR_POSIX_reserved36		(__NR_POSIX + 204)
-#define __NR_POSIX_reserved37		(__NR_POSIX + 205)
-#define __NR_POSIX_reserved38		(__NR_POSIX + 206)
-#define __NR_POSIX_reserved39		(__NR_POSIX + 207)
-#define __NR_POSIX_reserved40		(__NR_POSIX + 208)
-#define __NR_POSIX_reserved41		(__NR_POSIX + 209)
-#define __NR_POSIX_reserved42		(__NR_POSIX + 210)
-#define __NR_POSIX_reserved43		(__NR_POSIX + 211)
-#define __NR_POSIX_reserved44		(__NR_POSIX + 212)
-#define __NR_POSIX_reserved45		(__NR_POSIX + 213)
-#define __NR_POSIX_reserved46		(__NR_POSIX + 214)
-#define __NR_POSIX_reserved47		(__NR_POSIX + 215)
-#define __NR_POSIX_reserved48		(__NR_POSIX + 216)
-#define __NR_POSIX_reserved49		(__NR_POSIX + 217)
-#define __NR_POSIX_reserved50		(__NR_POSIX + 218)
-#define __NR_POSIX_reserved51		(__NR_POSIX + 219)
-#define __NR_POSIX_reserved52		(__NR_POSIX + 220)
-#define __NR_POSIX_reserved53		(__NR_POSIX + 221)
-#define __NR_POSIX_reserved54		(__NR_POSIX + 222)
-#define __NR_POSIX_reserved55		(__NR_POSIX + 223)
-#define __NR_POSIX_reserved56		(__NR_POSIX + 224)
-#define __NR_POSIX_reserved57		(__NR_POSIX + 225)
-#define __NR_POSIX_reserved58		(__NR_POSIX + 226)
-#define __NR_POSIX_reserved59		(__NR_POSIX + 227)
-#define __NR_POSIX_reserved60		(__NR_POSIX + 228)
-#define __NR_POSIX_reserved61		(__NR_POSIX + 229)
-#define __NR_POSIX_reserved62		(__NR_POSIX + 230)
-#define __NR_POSIX_reserved63		(__NR_POSIX + 231)
-#define __NR_POSIX_reserved64		(__NR_POSIX + 232)
-#define __NR_POSIX_reserved65		(__NR_POSIX + 233)
-#define __NR_POSIX_reserved66		(__NR_POSIX + 234)
-#define __NR_POSIX_reserved67		(__NR_POSIX + 235)
-#define __NR_POSIX_reserved68		(__NR_POSIX + 236)
-#define __NR_POSIX_reserved69		(__NR_POSIX + 237)
-#define __NR_POSIX_reserved70		(__NR_POSIX + 238)
-#define __NR_POSIX_reserved71		(__NR_POSIX + 239)
-#define __NR_POSIX_reserved72		(__NR_POSIX + 240)
-#define __NR_POSIX_reserved73		(__NR_POSIX + 241)
-#define __NR_POSIX_reserved74		(__NR_POSIX + 242)
-#define __NR_POSIX_reserved75		(__NR_POSIX + 243)
-#define __NR_POSIX_reserved76		(__NR_POSIX + 244)
-#define __NR_POSIX_reserved77		(__NR_POSIX + 245)
-#define __NR_POSIX_reserved78		(__NR_POSIX + 246)
-#define __NR_POSIX_reserved79		(__NR_POSIX + 247)
-#define __NR_POSIX_reserved80		(__NR_POSIX + 248)
-#define __NR_POSIX_reserved81		(__NR_POSIX + 249)
-#define __NR_POSIX_reserved82		(__NR_POSIX + 250)
-#define __NR_POSIX_reserved83		(__NR_POSIX + 251)
-#define __NR_POSIX_reserved84		(__NR_POSIX + 252)
-#define __NR_POSIX_reserved85		(__NR_POSIX + 253)
-#define __NR_POSIX_reserved86		(__NR_POSIX + 254)
-#define __NR_POSIX_reserved87		(__NR_POSIX + 255)
-#define __NR_POSIX_reserved88		(__NR_POSIX + 256)
-#define __NR_POSIX_reserved89		(__NR_POSIX + 257)
-#define __NR_POSIX_reserved90		(__NR_POSIX + 258)
-#define __NR_POSIX_reserved91		(__NR_POSIX + 259)
-#define __NR_POSIX_netboot		(__NR_POSIX + 260)
-#define __NR_POSIX_netunboot		(__NR_POSIX + 261)
-#define __NR_POSIX_rdump		(__NR_POSIX + 262)
-#define __NR_POSIX_setsid		(__NR_POSIX + 263)
-#define __NR_POSIX_getmaxsig		(__NR_POSIX + 264)
-#define __NR_POSIX_sigpending		(__NR_POSIX + 265)
-#define __NR_POSIX_sigprocmask		(__NR_POSIX + 266)
-#define __NR_POSIX_sigsuspend		(__NR_POSIX + 267)
-#define __NR_POSIX_sigaction		(__NR_POSIX + 268)
-#define __NR_POSIX_MIPS_reserved1	(__NR_POSIX + 269)
-#define __NR_POSIX_MIPS_reserved2	(__NR_POSIX + 270)
-#define __NR_POSIX_MIPS_reserved3	(__NR_POSIX + 271)
-#define __NR_POSIX_MIPS_reserved4	(__NR_POSIX + 272)
-#define __NR_POSIX_MIPS_reserved5	(__NR_POSIX + 273)
-#define __NR_POSIX_MIPS_reserved6	(__NR_POSIX + 274)
-#define __NR_POSIX_MIPS_reserved7	(__NR_POSIX + 275)
-#define __NR_POSIX_MIPS_reserved8	(__NR_POSIX + 276)
-#define __NR_POSIX_MIPS_reserved9	(__NR_POSIX + 277)
-#define __NR_POSIX_MIPS_reserved10	(__NR_POSIX + 278)
-#define __NR_POSIX_MIPS_reserved11	(__NR_POSIX + 279)
-#define __NR_POSIX_TANDEM_reserved1	(__NR_POSIX + 280)
-#define __NR_POSIX_TANDEM_reserved2	(__NR_POSIX + 281)
-#define __NR_POSIX_TANDEM_reserved3	(__NR_POSIX + 282)
-#define __NR_POSIX_TANDEM_reserved4	(__NR_POSIX + 283)
-#define __NR_POSIX_TANDEM_reserved5	(__NR_POSIX + 284)
-#define __NR_POSIX_TANDEM_reserved6	(__NR_POSIX + 285)
-#define __NR_POSIX_TANDEM_reserved7	(__NR_POSIX + 286)
-#define __NR_POSIX_TANDEM_reserved8	(__NR_POSIX + 287)
-#define __NR_POSIX_TANDEM_reserved9	(__NR_POSIX + 288)
-#define __NR_POSIX_TANDEM_reserved10	(__NR_POSIX + 289)
-#define __NR_POSIX_TANDEM_reserved11	(__NR_POSIX + 290)
-#define __NR_POSIX_TANDEM_reserved12	(__NR_POSIX + 291)
-#define __NR_POSIX_TANDEM_reserved13	(__NR_POSIX + 292)
-#define __NR_POSIX_TANDEM_reserved14	(__NR_POSIX + 293)
-#define __NR_POSIX_TANDEM_reserved15	(__NR_POSIX + 294)
-#define __NR_POSIX_TANDEM_reserved16	(__NR_POSIX + 295)
-#define __NR_POSIX_TANDEM_reserved17	(__NR_POSIX + 296)
-#define __NR_POSIX_TANDEM_reserved18	(__NR_POSIX + 297)
-#define __NR_POSIX_TANDEM_reserved19	(__NR_POSIX + 298)
-#define __NR_POSIX_TANDEM_reserved20	(__NR_POSIX + 299)
-#define __NR_POSIX_SGI_reserved7	(__NR_POSIX + 300)
-#define __NR_POSIX_SGI_reserved8	(__NR_POSIX + 301)
-#define __NR_POSIX_SGI_reserved9	(__NR_POSIX + 302)
-#define __NR_POSIX_SGI_reserved10	(__NR_POSIX + 303)
-#define __NR_POSIX_SGI_reserved11	(__NR_POSIX + 304)
-#define __NR_POSIX_SGI_reserved12	(__NR_POSIX + 305)
-#define __NR_POSIX_SGI_reserved13	(__NR_POSIX + 306)
-#define __NR_POSIX_SGI_reserved14	(__NR_POSIX + 307)
-#define __NR_POSIX_SGI_reserved15	(__NR_POSIX + 308)
-#define __NR_POSIX_SGI_reserved16	(__NR_POSIX + 309)
-#define __NR_POSIX_SGI_reserved17	(__NR_POSIX + 310)
-#define __NR_POSIX_SGI_reserved18	(__NR_POSIX + 311)
-#define __NR_POSIX_SGI_reserved19	(__NR_POSIX + 312)
-#define __NR_POSIX_SGI_reserved20	(__NR_POSIX + 313)
-#define __NR_POSIX_SGI_reserved21	(__NR_POSIX + 314)
-#define __NR_POSIX_SGI_reserved22	(__NR_POSIX + 315)
-#define __NR_POSIX_SGI_reserved23	(__NR_POSIX + 316)
-#define __NR_POSIX_SGI_reserved24	(__NR_POSIX + 317)
-#define __NR_POSIX_SGI_reserved25	(__NR_POSIX + 318)
-#define __NR_POSIX_SGI_reserved26	(__NR_POSIX + 319)
-
-#endif /* _ASM_RISCOS_SYSCALL_H */


From Don_Hiatt@pmc-sierra.com Wed Sep 14 23:59:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Sep 2005 23:59:40 +0100 (BST)
Received: from father.pmc-sierra.com ([IPv6:::ffff:216.241.224.13]:18397 "HELO
	father.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8224992AbVINW7V>; Wed, 14 Sep 2005 23:59:21 +0100
Received: (qmail 306 invoked by uid 101); 14 Sep 2005 22:59:14 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by father.pmc-sierra.com with SMTP; 14 Sep 2005 22:59:14 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j8EMxA45007683
	for <linux-mips@linux-mips.org>; Wed, 14 Sep 2005 15:59:14 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <RMQMT5N0>; Wed, 14 Sep 2005 15:59:18 -0700
Message-ID: <5C1FD43E5F1B824E83985A74F396286E5E9475@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Cc:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
Subject: Trival shell script crashes under 2.4.25
Date:	Wed, 14 Sep 2005 16:00:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Don_Hiatt@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8959
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Don_Hiatt@pmc-sierra.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2571
Lines: 97

Hello,

  Sorry if this is the wrong list to post to; if it is, could you
please suggest an alternative? :)

  Below you will find a very simple shell script that crashes under
2.4.25 running on a RM9000 (PMC rm7935) with busybox 1.0. This script
just demonstrates the actual problem but I do not believe it is 
isolated to busybox. In fact I wrote a simple program that just does
this:
	* for(;;)
		* fork()
			* mmap file "foo"
			* compare "foo" to an array image
		* waitpid()

and it will run for a while and then SEGFAULT at various times. According
to GDB the stack is corrupted and looking at the PC it does seem bogus
(0x2acf2e50). 

  The program crashes after a random amount of time but generally no more
that a minute or so. I can speed up the process if I ping-flood the target.

  Now what is really wierd is that if I run the program under gdbserver
it doesn't crash (or at least has not in the last 1/2 hour). Does gdbserver
change the execution context differently that gdb??

  Any suggestions would be greatly appreciated. :)

Cheers,

don


# cat die.sh 
#!/bin/sh
while :
do
  echo 1
done


*** RUN #1 ***
1
1
....
./die.sh: 5: echo: Bad address

*** RUN # 2 ***
1
1
1
..
Segmentation fault

*** GDB (6.3) DUMP ***
...
----------
fork()
P(16814) : C(17343) : Count (468)

Program received signal SIGSEGV, Segmentation fault.
0x2acf2e50 in ?? ()
(gdb) .
(gdb) bt
#0  0x2acf2e50 in ?? ()
warning: GDB can't find the start of the function at 0x2acf2e50.

    GDB is unable to find the start of the function at 0x2acf2e50
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2acf2e50 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#1  0x2acf2e50 in ?? ()
warning: GDB can't find the start of the function at 0x2acf2e50.
Previous frame identical to this frame (corrupt stack?)
(gdb)


*** CPU INFO ***
~ # cat /proc/cpuinfo 
system type             : ITE QED-4N-S01B
processor               : 0
cpu model               : RM9000 V2.2  FPU V2.0
BogoMIPS                : 897.84
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

From anemo@mba.ocn.ne.jp Thu Sep 15 17:16:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Sep 2005 17:16:31 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:25583 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225326AbVIOQQC>; Thu, 15 Sep 2005 17:16:02 +0100
Received: from localhost (p4183-ipad27funabasi.chiba.ocn.ne.jp [220.107.195.183])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id A4B2F85C1; Fri, 16 Sep 2005 01:15:57 +0900 (JST)
Date:	Fri, 16 Sep 2005 01:17:38 +0900 (JST)
Message-Id: <20050916.011738.41198368.anemo@mba.ocn.ne.jp>
To:	ralf@linux-mips.org
Cc:	macro@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050907.234413.108737010.anemo@mba.ocn.ne.jp>
References: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
	<20050907134717.GA3493@linux-mips.org>
	<20050907.234413.108737010.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8960
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 836
Lines: 28

>>>>> On Wed, 07 Sep 2005 23:44:13 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> So my "which is preferred" question was inappropriate.  I had
anemo> to ask "#1 or #2 or both or other ?"

In 2.6.14-rc1, another fix is done in arch/i386/kernel/entry.S.
It also fixes a race condition in signal delivery.

>    [PATCH] i386: Don't miss pending signals returning to user mode after signal processing
>    
>    Signed-off-by: Roland McGrath <roland@redhat.com>

Let's follow.

--- linux-mips/arch/mips/kernel/entry.S	2005-03-04 22:17:29.000000000 +0900
+++ linux/arch/mips/kernel/entry.S	2005-09-16 01:04:52.365022536 +0900
@@ -105,7 +105,7 @@
 	move	a0, sp
 	li	a1, 0
 	jal	do_notify_resume	# a2 already loaded
-	j	restore_all
+	j	resume_userspace
 
 FEXPORT(syscall_exit_work_partial)
 	SAVE_STATIC

---
Atsushi Nemoto

From ralf@linux-mips.org Thu Sep 15 17:44:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Sep 2005 17:44:57 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:21005 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225339AbVIOQok>; Thu, 15 Sep 2005 17:44:40 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8FGiYN8012813;
	Thu, 15 Sep 2005 17:44:34 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8FGiXcc012812;
	Thu, 15 Sep 2005 17:44:33 +0100
Date:	Thu, 15 Sep 2005 17:44:33 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	macro@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: unkillable process due to setup_frame() failure
Message-ID: <20050915164433.GS3224@linux-mips.org>
References: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl> <20050907134717.GA3493@linux-mips.org> <20050907.234413.108737010.anemo@mba.ocn.ne.jp> <20050916.011738.41198368.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050916.011738.41198368.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8961
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 108
Lines: 7

On Fri, Sep 16, 2005 at 01:17:38AM +0900, Atsushi Nemoto wrote:

> Let's follow.

Indeed.  Applied,

  Ralf

From ralf@linux-mips.org Thu Sep 15 20:18:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Sep 2005 20:18:18 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:43277 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225362AbVIOTSD>; Thu, 15 Sep 2005 20:18:03 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8FJHvU2017701;
	Thu, 15 Sep 2005 20:17:57 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8FJHm83017700;
	Thu, 15 Sep 2005 20:17:48 +0100
Date:	Thu, 15 Sep 2005 20:17:47 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Trival shell script crashes under 2.4.25
Message-ID: <20050915191747.GT3224@linux-mips.org>
References: <5C1FD43E5F1B824E83985A74F396286E5E9475@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5C1FD43E5F1B824E83985A74F396286E5E9475@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8962
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1412
Lines: 38

On Wed, Sep 14, 2005 at 04:00:40PM -0700, Don Hiatt wrote:

>   Sorry if this is the wrong list to post to; if it is, could you
> please suggest an alternative? :)

How about linux-mips ;-)

>   Below you will find a very simple shell script that crashes under
> 2.4.25 running on a RM9000 (PMC rm7935) with busybox 1.0. This script
> just demonstrates the actual problem but I do not believe it is 
> isolated to busybox. In fact I wrote a simple program that just does
> this:
> 	* for(;;)
> 		* fork()
> 			* mmap file "foo"
> 			* compare "foo" to an array image
> 		* waitpid()

linux-mips.org has no RM9000 support in it's 2.4 code.  That leaves
it up to guessing what could be happening in your codebase.

> and it will run for a while and then SEGFAULT at various times. According
> to GDB the stack is corrupted and looking at the PC it does seem bogus
> (0x2acf2e50). 

That would be a typical address for a shared library.

>   The program crashes after a random amount of time but generally no more
> that a minute or so. I can speed up the process if I ping-flood the target.
> 
>   Now what is really wierd is that if I run the program under gdbserver
> it doesn't crash (or at least has not in the last 1/2 hour). Does gdbserver
> change the execution context differently that gdb??

Strange indeed.  Both shouldn't affect the state of a running program
as long as it isn't being stopped.

  Ralf

From imipak@yahoo.com Thu Sep 15 21:59:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Sep 2005 21:59:30 +0100 (BST)
Received: from web31515.mail.mud.yahoo.com ([IPv6:::ffff:68.142.198.144]:53384
	"HELO web31515.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225479AbVIOU7L>; Thu, 15 Sep 2005 21:59:11 +0100
Received: (qmail 16382 invoked by uid 60001); 15 Sep 2005 20:59:04 -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=Bqn2fwTTrYcAZGn3ViQDf7313JRRIfRNJ6ioZHLrosObxE9GLrxKdSWRFm9ay+JoIgCUJCDcBcL/dOS+9Fs9HhGwty9+1sxGvCnMVAzmIKOagbgePV1SI2oC2fZf6layNDEoCuEEY2Q4IHt2J+ro6Wd2aELfQqhfZtwZ+wIKEN8=  ;
Message-ID: <20050915205904.16380.qmail@web31515.mail.mud.yahoo.com>
Received: from [208.187.37.98] by web31515.mail.mud.yahoo.com via HTTP; Thu, 15 Sep 2005 13:59:04 PDT
Date:	Thu, 15 Sep 2005 13:59:04 -0700 (PDT)
From:	Jonathan Day <imipak@yahoo.com>
Subject: Building the kernel for a Broadcom SB1
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <imipak@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8963
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: imipak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1563
Lines: 44

Hi,

I'm having a few issues building the current
2.6.14-rc1 for a Broadcom SB1 MIPS64 processor. (No
huge surprise there, building anything for that
processor is a pain.)

Anyway, there are a few symbols undefined, which is
causing problems. First off the bat is TO_PHYS_MASK.
There is no set of definitions in
include/asm-mips/addrspace.h for the SB1 processor.
(For that matter, there's no set of definitions for
the MIPS64_R2, so I'm guessing those using _R2 chips
probably have the same problem.)

For the time-being, I've simply grouped the SB1 with
the MIPS64_R1 as the SiByte documentation is rather
limited on what the SB1 actually is.

Next off, if you enable processor threading, it looks
for IRQ_PER_CPU. A grep reveals that this needs
ARCH_HAS_IRQ_PER_CPU defined in the architecture's
irq.h file, but that no such definition exists for any
MIPS processor.

A Google shows that the processor threading was
recently added in (or back in, or something). Is the
change to irq.h not present for a reason (eg:
something is broken, so the code shouldn't be used
anyway), something that should have been checked out
but wasn't (ie: my computer has turned traitor) or got
forgotten somewhere else in the chain?

For the time-being, I've simply added a #define for it
in the include/asm-mips/irq.h file, but it would be
good to know what the "correct" solution was.

Any help would be much appreciated.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From mark.e.mason@broadcom.com Thu Sep 15 22:53:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Sep 2005 22:53:26 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:216.31.210.19]:36879 "EHLO
	MMS3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225479AbVIOVxE>; Thu, 15 Sep 2005 22:53:04 +0100
Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom
 SMTP Relay (Email Firewall v6.1.0)); Thu, 15 Sep 2005 14:52:21 -0700
X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887
Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by
 mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID#
 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 15 Sep 2005 14:52:41
 -0700
Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com
 [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP
 id BUM06576; Thu, 15 Sep 2005 14:52:42 -0700 (PDT)
Received: from nt-sjca-0740.brcm.ad.broadcom.com (
 nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by
 mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA26498; Thu, 15
 Sep 2005 14:52:42 -0700 (PDT)
Received: from NT-SJCA-0750.brcm.ad.broadcom.com ([10.16.192.220]) by
 nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211);
 Thu, 15 Sep 2005 14:52:40 -0700
Received: from [127.0.0.1] ([10.240.253.31]) by
 NT-SJCA-0750.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211);
 Thu, 15 Sep 2005 14:52:40 -0700
Message-ID: <4329ED24.50506@broadcom.com>
Date:	Thu, 15 Sep 2005 14:52:36 -0700
From:	"Mark Mason" <mason@broadcom.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	"Jonathan Day" <imipak@yahoo.com>
cc:	linux-mips@linux-mips.org
Subject: Re: Building the kernel for a Broadcom SB1
References: <20050915205904.16380.qmail@web31515.mail.mud.yahoo.com>
In-Reply-To: <20050915205904.16380.qmail@web31515.mail.mud.yahoo.com>
X-OriginalArrivalTime: 15 Sep 2005 21:52:41.0018 (UTC)
 FILETIME=[CB85D9A0:01C5BA3F]
X-WSS-ID: 6F37329F20G1881239-01-01
Content-Type: text/plain;
 charset=iso-8859-1;
 format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <mark.e.mason@broadcom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8964
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mason@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1619
Lines: 48

Hello,

Jonathan Day wrote:

>Hi,
>
>I'm having a few issues building the current
>2.6.14-rc1 for a Broadcom SB1 MIPS64 processor. (No
>huge surprise there, building anything for that
>processor is a pain.)
>
>Anyway, there are a few symbols undefined, which is
>causing problems. First off the bat is TO_PHYS_MASK.
>There is no set of definitions in
>include/asm-mips/addrspace.h for the SB1 processor.
>(For that matter, there's no set of definitions for
>the MIPS64_R2, so I'm guessing those using _R2 chips
>probably have the same problem.)
>  
>
Here's the patch for that particular problem.  There's also a few other 
patches for the SB1 floating around (check the email archives), but 
there appears to be a backlog with getting them committed to the CVS 
repository.

HTH,
Mark

Index: include/asm-mips/addrspace.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/addrspace.h,v
retrieving revision 1.18
diff -u -p -r1.18 addrspace.h
--- include/asm-mips/addrspace.h    14 Jul 2005 12:05:08 -0000    1.18
+++ include/asm-mips/addrspace.h    15 Sep 2005 21:46:56 -0000
@@ -131,6 +131,8 @@
     || defined (CONFIG_CPU_R5000)                    \
     || defined (CONFIG_CPU_NEVADA)                    \
     || defined (CONFIG_CPU_TX49XX)                    \
+    || defined (CONFIG_CPU_SB1)                        \
+    || defined (CONFIG_CPU_SB1A)                    \
     || defined (CONFIG_CPU_MIPS64_R1)
 #define KUSIZE        _LLCONST_(0x0000010000000000)    /* 2^^40 */
 #define KUSIZE_64    _LLCONST_(0x0000010000000000)    /* 2^^40 */
.




From ihollo@tom.com Fri Sep 16 09:31:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 09:31:19 +0100 (BST)
Received: from smtpr3.tom.com ([IPv6:::ffff:202.108.255.198]:5532 "HELO
	tom.com") by linux-mips.org with SMTP id <S8225074AbVIPIbB>;
	Fri, 16 Sep 2005 09:31:01 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp5 (Coremail) with SMTP id OgBdPLKCKkM+ACac.1
	for <linux-mips@linux-mips.org>; Fri, 16 Sep 2005 16:30:54 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <432A82AA.3070002@tom.com>
Date:	Fri, 16 Sep 2005 16:30:34 +0800
From:	Zhuang Yuyao <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: pre-compiled cygwin mipsisa32-elf development enviroment
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ihollo@tom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8965
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ihollo@tom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 283
Lines: 11

Hi,

Does any know where I can download pre-compiled mipsisa32-elf 
gcc/binutils/libc for cygwin? I am not familar to cygwin enviroment but 
the ADM5120 bootloader source code I've got from admtek tech support 
seems can only be compiled by cygwin.

Thanks very much.

Zhuang Yuyao


From bjzheng@ict.ac.cn Fri Sep 16 10:20:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 10:21:04 +0100 (BST)
Received: from webmail.ict.ac.cn ([IPv6:::ffff:159.226.39.7]:57223 "HELO
	ict.ac.cn") by linux-mips.org with SMTP id <S8225074AbVIPJUr>;
	Fri, 16 Sep 2005 10:20:47 +0100
Received: (qmail 23985 invoked by uid 507); 16 Sep 2005 09:18:12 -0000
Received: from unknown (HELO ?159.226.40.185?) (bjzheng@159.226.40.185)
  by ict.ac.cn with SMTP; 16 Sep 2005 09:18:12 -0000
Message-ID: <432A8E5E.3090703@ict.ac.cn>
Date:	Fri, 16 Sep 2005 17:20:30 +0800
From:	=?GB2312?B?IlpoZW5nIEJhb0ppYW4gPNajsaO9qD4i?= <bjzheng@ict.ac.cn>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: zh-cn,zh
MIME-Version: 1.0
To:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: debug user-level application with ejtag
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Return-Path: <bjzheng@ict.ac.cn>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8966
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bjzheng@ict.ac.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 365
Lines: 16

Hi all:

I want to debug a user-level application with ejtag,during app running i
list cpu register with ejtag,system report "Bus error",Who have debuged
user app with ejtag?
Best Regards.

-- 
Baojian Zheng
Institute of Computing Technology
Chinese Academy of Sciences
P.O. Box 2704-25
Beijing, China,100080
Tel: 86-10-62565533 ex. 9311
E-mail: bjzheng@ict.ac.cn


From cw@f00f.org Fri Sep 16 10:27:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 10:27:44 +0100 (BST)
Received: from ylpvm29-ext.prodigy.net ([IPv6:::ffff:207.115.57.60]:51619 "EHLO
	ylpvm29.prodigy.net") by linux-mips.org with ESMTP
	id <S8225074AbVIPJ10>; Fri, 16 Sep 2005 10:27:26 +0100
Received: from pimout3-ext.prodigy.net (pimout3-int.prodigy.net [207.115.4.218])
	by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j8G9R41C005225
	for <linux-mips@linux-mips.org>; Fri, 16 Sep 2005 05:27:06 -0400
X-ORBL:	[67.124.117.85]
Received: from stupidest.org (adsl-67-124-117-85.dsl.snfc21.pacbell.net [67.124.117.85])
	by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j8G9RI7b420246;
	Fri, 16 Sep 2005 05:27:22 -0400
Received: by taniwha.stupidest.org (Postfix, from userid 38689)
	id 82428528F26; Fri, 16 Sep 2005 02:27:18 -0700 (PDT)
Date:	Fri, 16 Sep 2005 02:27:18 -0700
From:	Chris Wedgwood <cw@f00f.org>
To:	"\"Zheng BaoJian <??????>\"" <bjzheng@ict.ac.cn>
Cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: debug user-level application with ejtag
Message-ID: <20050916092718.GA15749@taniwha.stupidest.org>
References: <432A8E5E.3090703@ict.ac.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <432A8E5E.3090703@ict.ac.cn>
Return-Path: <cw@f00f.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8967
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cw@f00f.org
Precedence: bulk
X-list: linux-mips
Content-Length: 425
Lines: 11

On Fri, Sep 16, 2005 at 05:20:30PM +0800, "Zheng BaoJian <??????>" wrote:

> I want to debug a user-level application with ejtag,during app
> running i list cpu register with ejtag,system report "Bus error",Who
> have debuged user app with ejtag?

generally speaking this won't work in any reliable manner (it probably
could be made to work reliably given enough effort but i doubt anyone
will bother)

try gdbserver instead

From vlad@woody.ci.ukrpack.net Fri Sep 16 10:49:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 10:49:38 +0100 (BST)
Received: from woody.ci.ukrpack.net ([IPv6:::ffff:212.1.120.12]:45459 "EHLO
	woody.ci.ukrpack.net") by linux-mips.org with ESMTP
	id <S8225245AbVIPJtX>; Fri, 16 Sep 2005 10:49:23 +0100
Received: (qmail 29144 invoked by uid 600); 16 Sep 2005 12:49:14 +0300
Date:	Fri, 16 Sep 2005 12:49:14 +0300
From:	Vladislav Moskovets <linux-mips-ml@vlad.org.ua>
To:	linux-mips@linux-mips.org
Subject: Re: [ADMtek 5120] 64M sdram on board but only 16M is deteted and usable
Message-ID: <20050916094914.GI3353@woody>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Return-Path: <vlad@woody.ci.ukrpack.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8968
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux-mips-ml@vlad.org.ua
Precedence: bulk
X-list: linux-mips
Content-Length: 473
Lines: 17

Hi, we have successful experience with bootloader patching, we have
working 32M
If you want we can publish our work

> I've just upgraded the SDRAM on my adm5120 board from 16M to 64M, but
> while the board is booting, it still reports that only 16M sdram is
> availible.
> Since I do not have the source code of the bootloader, is there any
> way
> to let the board to boot with 64M sdram, or should I change to another
> bootloader?


-- 
Regards, Vladislav Moskovets
 


From Don_Hiatt@pmc-sierra.com Fri Sep 16 16:37:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 16:39:33 +0100 (BST)
Received: from father.pmc-sierra.com ([IPv6:::ffff:216.241.224.13]:52726 "HELO
	father.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225225AbVIPPha>; Fri, 16 Sep 2005 16:37:30 +0100
Received: (qmail 26363 invoked by uid 101); 16 Sep 2005 15:37:19 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by father.pmc-sierra.com with SMTP; 16 Sep 2005 15:37:19 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j8GFbJJg013205
	for <linux-mips@linux-mips.org>; Fri, 16 Sep 2005 08:37:19 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <RMQMVC0S>; Fri, 16 Sep 2005 08:37:26 -0700
Message-ID: <5C1FD43E5F1B824E83985A74F396286E5E9483@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
To:	linux-mips@linux-mips.org
Subject: Location of MIPS KDB Patch? 
Date:	Fri, 16 Sep 2005 08:38:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Don_Hiatt@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8969
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Don_Hiatt@pmc-sierra.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1213
Lines: 45


Howdy,

 I've included the response (hope Keith doesn't mind) I got about
the MIPS patch for KDB. Is there in fact a MIPS patch for KDB? According
to Sergey there is:

(http://www.linux-mips.org/archives/linux-mips/2005-08/msg00117.html)
>It works fine, I'm using it on NEC VR5701

>Best wishes,
>Sergey Podstavin.

On Mon, 2005-08-22 at 18:00 -0700, Knittel, Brian wrote:
> There are a couple of references to KDB in the archive, but nothing recent. 
> What is the state of KDB on MIPS?
>  
> Thanks,
> --Brian
> 
> 

Cheers,

don


-----Original Message-----
From: Keith Owens [mailto:kaos@sgi.com]
Sent: Thursday, September 15, 2005 5:01 PM
To: Don Hiatt
Cc: 'kdb@oss.sgi.com'
Subject: Re: Location of MIPS KDB Patch? 


On Thu, 15 Sep 2005 09:57:19 -0700, 
Don Hiatt <Don_Hiatt@pmc-sierra.com> wrote:
>  I was wondering where I could find the MIPS specific patch for
>KDB for 2.4.25? I've found the common-portions on the FTP site but
>seem to be missing the MIPS part. Sorry if this is detailed somewhere
>which I have likely overlooked. ;)

KDB has never been supported on MIPS.  Over the years several people
with MIPS hardware have said that they would have a go at it, but
nobody ever sent any patches.

From spodstavin@ru.mvista.com Fri Sep 16 16:57:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 16:58:17 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.6] ([IPv6:::ffff:85.21.88.6]:29476 "EHLO
	buildserver.ru.mvista.com") by linux-mips.org with ESMTP
	id <S8225287AbVIPP54>; Fri, 16 Sep 2005 16:57:56 +0100
Received: from 192.168.1.133 ([10.150.0.9])
	by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id j8GFvht32355;
	Fri, 16 Sep 2005 20:57:43 +0500
Subject: Re: Location of MIPS KDB Patch?
From:	Sergey Podstavin <spodstavin@ru.mvista.com>
Reply-To: spodstavin@ru.mvista.com
To:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <5C1FD43E5F1B824E83985A74F396286E5E9483@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
References: <5C1FD43E5F1B824E83985A74F396286E5E9483@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Content-Type: text/plain
Organization: MontaVista
Date:	Fri, 16 Sep 2005 19:57:53 +0400
Message-Id: <1126886273.5631.6.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
Content-Transfer-Encoding: 7bit
Return-Path: <spodstavin@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8970
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: spodstavin@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 678
Lines: 28

Sorry, I had written about KGDB.

Best wishes,
Sergey Podstavin.

On Fri, 2005-09-16 at 08:38 -0700, Don Hiatt wrote:
> Howdy,
> 
>  I've included the response (hope Keith doesn't mind) I got about
> the MIPS patch for KDB. Is there in fact a MIPS patch for KDB? According
> to Sergey there is:
> 
> (http://www.linux-mips.org/archives/linux-mips/2005-08/msg00117.html)
> >It works fine, I'm using it on NEC VR5701
> 
> >Best wishes,
> >Sergey Podstavin.
> 
> On Mon, 2005-08-22 at 18:00 -0700, Knittel, Brian wrote:
> > There are a couple of references to KDB in the archive, but nothing recent. 
> > What is the state of KDB on MIPS?
> >  
> > Thanks,
> > --Brian
> > 
> > 



From Don_Hiatt@pmc-sierra.com Fri Sep 16 17:06:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 17:07:00 +0100 (BST)
Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:64192 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8225291AbVIPQGn>; Fri, 16 Sep 2005 17:06:43 +0100
Received: (qmail 20732 invoked by uid 101); 16 Sep 2005 16:06:30 -0000
Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236)
  by mother.pmc-sierra.com with SMTP; 16 Sep 2005 16:06:30 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id j8GG6U90013797
	for <linux-mips@linux-mips.org>; Fri, 16 Sep 2005 09:06:30 -0700
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <RMQMVDXK>; Fri, 16 Sep 2005 09:06:37 -0700
Message-ID: <5C1FD43E5F1B824E83985A74F396286E5E9486@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
From:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
To:	linux-mips@linux-mips.org
Subject: RE: Location of MIPS KDB Patch? 
Date:	Fri, 16 Sep 2005 09:07:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Return-Path: <Don_Hiatt@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8971
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Don_Hiatt@pmc-sierra.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1643
Lines: 63

I know it is bad etiquette to reply to your own message, but... :)

I just got an email from Sergey and he was referring to KGDB. So
the mystery remains, has anyone already ported KDB? And if not, is
it worth it when compared to KGDB (I haven't used either)?

Cheers,

don


-----Original Message-----
From: Don Hiatt 
Sent: Friday, September 16, 2005 8:39 AM
To: linux-mips@linux-mips.org
Subject: Location of MIPS KDB Patch? 



Howdy,

 I've included the response (hope Keith doesn't mind) I got about
the MIPS patch for KDB. Is there in fact a MIPS patch for KDB? According
to Sergey there is:

(http://www.linux-mips.org/archives/linux-mips/2005-08/msg00117.html)
>It works fine, I'm using it on NEC VR5701

>Best wishes,
>Sergey Podstavin.

On Mon, 2005-08-22 at 18:00 -0700, Knittel, Brian wrote:
> There are a couple of references to KDB in the archive, but nothing recent. 
> What is the state of KDB on MIPS?
>  
> Thanks,
> --Brian
> 
> 

Cheers,

don


-----Original Message-----
From: Keith Owens [mailto:kaos@sgi.com]
Sent: Thursday, September 15, 2005 5:01 PM
To: Don Hiatt
Cc: 'kdb@oss.sgi.com'
Subject: Re: Location of MIPS KDB Patch? 


On Thu, 15 Sep 2005 09:57:19 -0700, 
Don Hiatt <Don_Hiatt@pmc-sierra.com> wrote:
>  I was wondering where I could find the MIPS specific patch for
>KDB for 2.4.25? I've found the common-portions on the FTP site but
>seem to be missing the MIPS part. Sorry if this is detailed somewhere
>which I have likely overlooked. ;)

KDB has never been supported on MIPS.  Over the years several people
with MIPS hardware have said that they would have a go at it, but
nobody ever sent any patches.

From sjhill@realitydiluted.com Fri Sep 16 19:53:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Sep 2005 19:54:09 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:8110 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225428AbVIPSxu>; Fri, 16 Sep 2005 19:53:50 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.52 #1 (Debian))
	id 1EGKPJ-0005Pf-1K; Fri, 16 Sep 2005 12:53:53 -0500
Subject: Re: Location of MIPS KDB Patch?
In-Reply-To: <5C1FD43E5F1B824E83985A74F396286E5E9486@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
To:	Don Hiatt <Don_Hiatt@pmc-sierra.com>
Date:	Fri, 16 Sep 2005 12:53:52 -0500 (CDT)
CC:	linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1EGKPJ-0005Pf-1K@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8972
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 610
Lines: 12

> I just got an email from Sergey and he was referring to KGDB. So
> the mystery remains, has anyone already ported KDB? And if not, is
> it worth it when compared to KGDB (I haven't used either)?
> 
Use printk or a hardware debugger. Software kernel debuggers almost
never work and they're always buggy. The guys who did KGDB for MIPS
did a great job, but it looks like it's hard to keep that code up
to date and working with kernel changes and newer versions of gdb.
At least that's been my experience. In-kernel debuggers is like
saying "Physician heal thyself." or asking yourself to be objective.

-Steve

From michaelanburaj@hotmail.com Sat Sep 17 06:24:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Sep 2005 06:24:26 +0100 (BST)
Received: from bay107-f35.bay107.hotmail.com ([IPv6:::ffff:64.4.51.45]:57182
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8224794AbVIQFYC>; Sat, 17 Sep 2005 06:24:02 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 16 Sep 2005 22:23:57 -0700
Message-ID: <BAY107-F351BA7EDDB556764AF6903C9900@phx.gbl>
Received: from 64.4.51.220 by by107fd.bay107.hotmail.msn.com with HTTP;
	Sat, 17 Sep 2005 05:23:56 GMT
X-Originating-IP: [64.4.51.220]
X-Originating-Email: [michaelanburaj@hotmail.com]
X-Sender: michaelanburaj@hotmail.com
In-Reply-To: <Pine.LNX.4.61L.0507191301220.10363@blysk.ds.pg.gda.pl>
From:	"Michael Anburaj" <michaelanburaj@hotmail.com>
To:	linux-mips@linux-mips.org
Subject: linux 2.6.10 on MIPS Atlas 4Kc -- SAA9730 driver issue
Date:	Fri, 16 Sep 2005 22:23:56 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 17 Sep 2005 05:23:57.0230 (UTC) FILETIME=[009DACE0:01C5BB48]
Return-Path: <michaelanburaj@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8973
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 5081
Lines: 153

Hi All,

Hardware: MIPS Atlas 4Kc
Linux: 2.6.10

I am having an issue with the SAA9730 driver. The kernel works fine other 
than this.

Problem:
I configure the interface & trying pinging outside, the IP packets make it 
to the xmit function in the driver & gets posted to the hardware, but does 
not get transmitted. And when I ping the interface from outside it causes an 
exception (I guess -- It hangs).The control comes to the interrupt handler 
in the driver -- on the way back it hangs.

Please let me know, what possibly could be wrong.

Thanks,
-Mike.

Following is the dump

#ifconfig eth0 192.168.1.105
lan_saa9730_open: IRQ17
lan_saa9730_open: pass
# Reserved instruction in kernel code in arch/mips/kernel/traps.c::do_ri, 
line :Cpu 0
$ 0   : 00000000 1000fc00 00000000 00000000
$ 4   : 80583f30 2ac2e020 00000001 00000000
$ 8   : 1000fc01 1000001e 00000001 804fe000
$12   : 00000000 00000000 80583e94 00000000
$16   : 80583f30 00000001 7fff6b30 00000000
$20   : 10010820 0000005b 10009898 10010000
$24   : 00000000 2ac2e000
$28   : 80582000 80583ee8 00000002 80107a28
Hi    : 12000000
Lo    : 0cf3b100
epc   : 8011a694 do_dsemulret+0x38/0xb4     Not tainted
ra    : 80107a28 do_ade+0x18/0x380
Status: 1000fc03    KERNEL EXL IE
Cause : 30800028
PrId  : 00018001
Modules linked in:
Process sh (pid: 52, threadinfo=80582000, task=8002cbc0)
Stack : 7fff6b30 00000001 10010820 80161c20 80107a28 2ac094d4 80561000 
00001000
        00000000 00001002 00000000 00000000 1000f1a6 00000001 1000f1a6 
00000001
        801017c4 8010a380 10010360 00001002 00000000 1000f318 ffffffff 
00000000
        00000000 1000fc00 00000001 2ac7cef4 00000000 7fff6b30 00000001 
00000000
        00000000 00000000 00000001 804fe000 00000000 00000000 80583e94 
00000000
        ...
Call Trace:
[<80161c20>] sys_read+0x58/0xa0
[<80107a28>] do_ade+0x18/0x380
[<801017c4>] handle_adel_int+0x38/0x54
[<8010a380>] tlb_do_page_fault_1+0x104/0x114


Code: 5440001c  00001021  00401821 <8ca60004> 8ca70008  00621825  14600006  
3c0
Reserved instruction in kernel code in arch/mips/kernel/traps.c::do_ri, line 
63:Cpu 0
$ 0   : 00000000 1000fc01 00000000 8036fbad
$ 4   : 0000003c 00000cf5 80e2fedc 00000000
$ 8   : 00000000 ffffffff 00000001 802e75b4
$12   : 8036eab1 fffffffe 80583c87 ffffffff
$16   : 802e4da0 00001000 7fff6da0 00000000
$20   : 00000002 7fff7ee4 0040672c 00000002
$24   : 00000010 00000007
$28   : 80e2e000 80e2fec0 004069a0 8011f158
Hi    : 12079999
Lo    : a692c28f
epc   : 8011f1f0 do_syslog+0x200/0x510     Not tainted
ra    : 8011f158 do_syslog+0x168/0x510
Status: 1000fc03    KERNEL EXL IE
Cause : 30800028
PrId  : 00018001
Modules linked in:
Process klogd (pid: 54, threadinfo=80e2e000, task=8002c400)
Stack : 00000035 00000006 00000002 801249b8 00000000 8002c400 801376c0 
80e2fedc
        80e2fedc 8013c560 00000000 8002c400 801376c0 80e2fedc 80e2fedc 
801064c8
        7fff6da0 00000035 00000035 00000006 8011f510 00000000 7fff6828 
7fff6844
        7fff685a 7fff6c27 801087e4 80100734 7fff79c0 7fff75c0 1000e018 
7fff71ba
        ffffffff 00000000 00000000 1000fc01 00001007 7fff7da0 00000002 
7fff6da0
        ...
Call Trace:
[<801249b8>] do_softirq+0x5c/0x90
[<801376c0>] autoremove_wake_function+0x0/0x4c
[<8013c560>] irq_exit+0x44/0x50
[<801376c0>] autoremove_wake_function+0x0/0x4c
[<801064c8>] ll_timer_interrupt+0x44/0x58
[<8011f510>] sys_syslog+0x10/0x1c
[<801087e4>] stack_done+0x20/0x3c
[<80100734>] mipsIRQ+0x114/0x160


Code: 40816000  00001021  00403821 <a2440000> 26520001  25080001  40016000  
000
Reserved instruction in kernel code in arch/mips/kernel/traps.c::do_ri, line 
63:Cpu 0
$ 0   : 00000000 1000fc01 00000000 00000000
$ 4   : 00000000 00000013 0000000b 804f7e40
$ 8   : 00000000 ffffffff 00000001 802e75b4
$12   : 8036eab1 fffffffe 80e2fc5f ffffffff
$16   : 8002cbc0 00000000 00000000 7fff7dc8
$20   : 00000000 01000000 00000001 804f5c68
$24   : 00000010 00000007
$28   : 804f8000 804f9e60 00000000 801232e8
Hi    : 1206147a
Lo    : ee3fbf0c
epc   : 80122868 wait_task_zombie+0x2d8/0x568     Not tainted
ra    : 801232e8 do_wait+0x204/0x4dc
Status: 1000fc03    KERNEL EXL IE
Cause : 30800028
PrId  : 00018001
Modules linked in:
Process init (pid: 1, threadinfo=804f8000, task=804f5bc0)
Stack : 804f9e68 803654bc c25bfe80 000f41fd fffffe00 804f5c68 804f5bc0 
00000004
        8002cbc0 8002cc70 804f5bc0 00000004 801232e8 801233ec 8665a700 
000f41fd
        804f9ed8 fffba8a5 00000000 7fff7ba8 00000000 804f5bc0 8011ba68 
804f5cd0
        804f5cd0 802aeb40 00000000 804f5bc0 8011ba68 00000000 00000000 
00200200
        00000000 00000000 0042efb8 7fff7f2c 00430000 0042e3e4 7fff7f24 
00000002
        ...
Call Trace:
[<801232e8>] do_wait+0x204/0x4dc
[<801233ec>] do_wait+0x308/0x4dc
[<8011ba68>] default_wake_function+0x0/0x2c
[<802aeb40>] schedule_timeout+0xb4/0xe4
[<8011ba68>] default_wake_function+0x0/0x2c
[<80123694>] sys_wait4+0x30/0x48
[<801087e4>] stack_done+0x20/0x3c
[<801087e4>] stack_done+0x20/0x3c


Code: 54400004  00408821  02201021 <ae660000> 00408821  1620006f  24020010  
124
Kernel panic - not syncing: Attempted to kill init!



From ppopov@embeddedalley.com Sun Sep 18 11:53:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Sep 2005 11:53:37 +0100 (BST)
Received: from smtp103.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.238]:184
	"HELO smtp103.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225472AbVIRKxK>; Sun, 18 Sep 2005 11:53:10 +0100
Received: (qmail 58956 invoked from network); 18 Sep 2005 10:53:03 -0000
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp103.biz.mail.mud.yahoo.com with SMTP; 18 Sep 2005 10:53:02 -0000
Subject: Re: [patch] little zImage.flash fixes
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Bruno Randolf <bruno.randolf@4g-systems.biz>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <200509141825.34038.bruno.randolf@4g-systems.biz>
References: <200509141825.34038.bruno.randolf@4g-systems.biz>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Sun, 18 Sep 2005 03:53:01 -0700
Message-Id: <1127040781.4948.34.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8974
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3380
Lines: 98


Thanks. I'll create a 2.6.13 patch later.

Pete

On Wed, 2005-09-14 at 18:25 +0200, Bruno Randolf wrote:
> hello!
> 
> fyi - i had to make the following changes after applying your 
> zImage_2_6_10.patch to use "make zImage.flash" on the recent 2.6.13 
> linux-mips kernel.  also "make zImage" wouldn't compile through without the 
> "-I $(TOPDIR)/include" changes.
> 
> greetings,
> bruno
> 
> ---
> 
> diff --exclude CVS -Nurb linux/arch/mips/Makefile 
> linux-2.6.13/arch/mips/Makefile
> --- linux/arch/mips/Makefile    2005-09-14 16:44:32.000000000 +0200
> +++ linux-2.6.13/arch/mips/Makefile     2005-09-14 16:32:28.000000000 +0200
> @@ -798,6 +798,9 @@
>  zImage: vmlinux
>         +@$(call makeboot,$@)
>  
> +zImage.flash: vmlinux
> +       +@$(call makeboot,$@)
> +
>  CLEAN_FILES += vmlinux.ecoff \
>                vmlinux.srec \
>                vmlinux.rm200.tmp \
> diff --exclude CVS -Nurb linux/arch/mips/boot/Makefile 
> linux-2.6.13/arch/mips/boot/Makefile
> --- linux/arch/mips/boot/Makefile       2005-09-14 16:44:32.000000000 +0200
> +++ linux-2.6.13/arch/mips/boot/Makefile        2005-09-14 16:35:14.000000000 
> +0200
> @@ -26,7 +26,7 @@
>  
>  VMLINUX = vmlinux
>  
> -ZBOOT_TARGETS  = zImage
> +ZBOOT_TARGETS  = zImage zImage.flash
>  bootdir-y      := compressed
>  
>  all: vmlinux.ecoff vmlinux.srec addinitrd zImage
> diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/Makefile 
> linux-2.6.13/arch/mips/boot/compressed/Makefile
> --- linux/arch/mips/boot/compressed/Makefile    2005-09-14 16:44:32.000000000 
> +0200
> +++ linux-2.6.13/arch/mips/boot/compressed/Makefile     2005-09-14 
> 16:31:53.000000000 +0200
> @@ -18,7 +18,7 @@
>  
>  CFLAGS         += -fno-builtin -D__BOOTER__ -I$(compressed)/include
>  
> -BOOT_TARGETS   = zImage 
> +BOOT_TARGETS   = zImage zImage.flash
>  
>  bootdir-$(CONFIG_SOC_AU1X00)   := au1xxx
>  subdir-y                       := common lib images
> diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/au1xxx/Makefile 
> linux-2.6.13/arch/mips/boot/compressed/au1xxx/Makefile
> --- linux/arch/mips/boot/compressed/au1xxx/Makefile     2005-09-14 
> 16:44:32.000000000 +0200
> +++ linux-2.6.13/arch/mips/boot/compressed/au1xxx/Makefile      2005-09-14 
> 16:38:34.000000000 +0200
> @@ -73,12 +73,12 @@
>  endif
>  
>  $(obj)/head.o: $(obj)/head.S $(TOPDIR)/vmlinux
> -       $(CC) $(AFLAGS) \
> +       $(CC) -I $(TOPDIR)/include $(AFLAGS) \
>         -DKERNEL_ENTRY=$(shell sh $(ENTRY) $(NM) $(TOPDIR)/vmlinux ) \
>         -c -o $*.o $<
>  
>  $(common)/misc-simple.o:
> -       $(CC) $(CFLAGS) -DINITRD_OFFSET=0 -DINITRD_SIZE=0 -DZIMAGE_OFFSET=0 \
> +       $(CC) -I $(TOPDIR)/include $(CFLAGS) -DINITRD_OFFSET=0 -DINITRD_SIZE=0 
> -DZIMAGE_OFFSET=0 \
>                 -DAVAIL_RAM_START=$(AVAIL_RAM_START) \
>                 -DAVAIL_RAM_END=$(AVAIL_RAM_END) \
>                 -DLOADADDR=$(LOADADDR) \
> diff --exclude CVS -Nurb linux/arch/mips/boot/compressed/common/misc-simple.c 
> linux-2.6.13/arch/mips/boot/compressed/common/misc-simple.c
> --- linux/arch/mips/boot/compressed/common/misc-simple.c        2005-09-14 
> 16:44:32.000000000 +0200
> +++ linux-2.6.13/arch/mips/boot/compressed/common/misc-simple.c 2005-09-14 
> 16:31:07.000000000 +0200
> @@ -24,7 +24,7 @@
>  
>  #include <asm/page.h>
>  
> -#include "zlib.h"
> +#include "linux/zlib.h"
>  
>  extern struct NS16550 *com_port;


From hch@lst.de Mon Sep 19 16:08:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 16:08:41 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:213.95.11.210]:8111 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225196AbVISPIY>;
	Mon, 19 Sep 2005 16:08:24 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j8JF8M6t013533
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 19 Sep 2005 17:08:22 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j8JF8M79013531;
	Mon, 19 Sep 2005 17:08:22 +0200
Date:	Mon, 19 Sep 2005 17:08:22 +0200
From:	Christoph Hellwig <hch@lst.de>
To:	ralf@linux-mips.org, akpm@osdl.org
Cc:	linux-mips@linux-mips.org
Subject: [PATCH] switch sibyte profiling driver to ->compat_ioctl
Message-ID: <20050919150822.GB13478@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8975
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1902
Lines: 68


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/arch/mips/kernel/ioctl32.c
===================================================================
--- linux-2.6.orig/arch/mips/kernel/ioctl32.c	2005-09-18 13:46:51.000000000 +0200
+++ linux-2.6/arch/mips/kernel/ioctl32.c	2005-09-19 15:14:05.000000000 +0200
@@ -41,12 +41,6 @@
 #define DECLARES
 #include "compat_ioctl.c"
 
-#ifdef CONFIG_SIBYTE_TBPROF
-COMPATIBLE_IOCTL(SBPROF_ZBSTART)
-COMPATIBLE_IOCTL(SBPROF_ZBSTOP)
-COMPATIBLE_IOCTL(SBPROF_ZBWAITFULL)
-#endif /* CONFIG_SIBYTE_TBPROF */
-
 /*HANDLE_IOCTL(RTC_IRQP_READ, w_long)
 COMPATIBLE_IOCTL(RTC_IRQP_SET)
 HANDLE_IOCTL(RTC_EPOCH_READ, w_long)
Index: linux-2.6/arch/mips/sibyte/sb1250/bcm1250_tbprof.c
===================================================================
--- linux-2.6.orig/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-18 13:46:52.000000000 +0200
+++ linux-2.6/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-19 15:13:53.000000000 +0200
@@ -28,6 +28,7 @@
 #include <linux/fs.h>
 #include <linux/errno.h>
 #include <linux/reboot.h>
+#include <linux/smp_lock.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/sibyte/sb1250.h>
@@ -333,13 +334,13 @@
 	return count;
 }
 
-static int sbprof_tb_ioctl(struct inode *inode,
-			   struct file *filp,
-			   unsigned int command,
-			   unsigned long arg)
+static long sbprof_tb_ioctl(struct file *filp,
+			    unsigned int command,
+			    unsigned long arg)
 {
 	int error = 0;
 
+	lock_kernel();
 	switch (command) {
 	case SBPROF_ZBSTART:
 		error = sbprof_zbprof_start(filp);
@@ -355,6 +356,7 @@
 		error = -EINVAL;
 		break;
 	}
+	unlock_kernel();
 
 	return error;
 }
@@ -364,7 +366,8 @@
 	.open		= sbprof_tb_open,
 	.release	= sbprof_tb_release,
 	.read		= sbprof_tb_read,
-	.ioctl		= sbprof_tb_ioctl,
+	.unlocked_ioctl	= sbprof_tb_ioctl,
+	.comapt_ioctl	= sbprof_tb_ioctl,
 	.mmap		= NULL,
 };
 

From ths@networkno.de Mon Sep 19 16:41:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 16:41:23 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:43484 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8225206AbVISPlD>;
	Mon, 19 Sep 2005 16:41:03 +0100
Received: from port-195-158-179-11.dynamic.qsc.de ([195.158.179.11] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1EHNlJ-0007Wf-00
	for linux-mips@linux-mips.org; Mon, 19 Sep 2005 17:40:57 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EHNlI-000360-RE
	for linux-mips@linux-mips.org; Mon, 19 Sep 2005 17:40:56 +0200
Date:	Mon, 19 Sep 2005 17:40:56 +0200
To:	linux-mips@linux-mips.org
Subject: Performance bug in c-r4k.c cache handling code
Message-ID: <20050919154056.GG3386@hattusa.textio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8976
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1267
Lines: 37

Hello All,

I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
Hit_Writeback_Inv instead of Hit_Invalidate is done. Ralf mentioned
this is probably due to broken Hit_Invalidate cache ops on some
CPUs, does anybody have more information about this? The appended
patch works apparently fine on R4400, R4600v2.0, R5000.


Thiemo


Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.119
diff -u -p -r1.119 c-r4k.c
--- arch/mips/mm/c-r4k.c	9 Sep 2005 20:26:54 -0000	1.119
+++ arch/mips/mm/c-r4k.c	19 Sep 2005 15:33:35 -0000
@@ -685,7 +685,7 @@ static void r4k_dma_cache_inv(unsigned l
 		a = addr & ~(sc_lsize - 1);
 		end = (addr + size - 1) & ~(sc_lsize - 1);
 		while (1) {
-			flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
+			invalidate_scache_line(a);	/* Hit_Invalidate_SD */
 			if (a == end)
 				break;
 			a += sc_lsize;
@@ -702,7 +702,7 @@ static void r4k_dma_cache_inv(unsigned l
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
+			invalidate_dcache_line(a);	/* Hit_Invalidate_D */
 			if (a == end)
 				break;
 			a += dc_lsize;

From anemo@mba.ocn.ne.jp Mon Sep 19 17:50:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 17:50:28 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:7106 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225386AbVISQuI>; Mon, 19 Sep 2005 17:50:08 +0100
Received: from localhost (p8077-ipad27funabasi.chiba.ocn.ne.jp [220.107.199.77])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id C1E4C861F; Tue, 20 Sep 2005 01:50:02 +0900 (JST)
Date:	Tue, 20 Sep 2005 01:48:36 +0900 (JST)
Message-Id: <20050920.014836.108305051.anemo@mba.ocn.ne.jp>
To:	macro@linux-mips.org
Cc:	spodstavin@ru.mvista.com, linux-mips@linux-mips.org,
	ralf@linux-mips.org
Subject: Re: a patch for generic MIPS RTC
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050907.005517.25909840.anemo@mba.ocn.ne.jp>
References: <20050905.224534.25910293.anemo@mba.ocn.ne.jp>
	<Pine.LNX.4.61L.0509051620020.29615@blysk.ds.pg.gda.pl>
	<20050907.005517.25909840.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8977
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 20343
Lines: 722

>>>>> On Wed, 07 Sep 2005 00:55:17 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> OK, and I also found some rtc routines might take a few
anemo> SECONDS, therefore protecting whole these rtc routines entirely
anemo> with spinlock is really bad idea.

anemo> How about this (untested) one?

Now one fix for asm-mips/rtc.h is done.
Here is a revised patch.  Comments are welcome.  Thank you.

* Get rid of mips_rtc_lock.
* Use rtc_lock (and disable irq) to protect HW access in each rtc routines.

diff -ur linux-mips/arch/mips/ddb5xxx/common/rtc_ds1386.c linux/arch/mips/ddb5xxx/common/rtc_ds1386.c
--- linux-mips/arch/mips/ddb5xxx/common/rtc_ds1386.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/ddb5xxx/common/rtc_ds1386.c	2005-09-20 01:39:27.315888352 +0900
@@ -41,7 +41,9 @@
 	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;
@@ -70,6 +72,7 @@
 		/* 24 hour format */
 		hour = BCD2BIN(temp & 0x3f);
 	}
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, month, day, hour, minute, second);
 }
@@ -81,7 +84,9 @@
 	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 @@
 	if (second != READ_RTC(0x1)) {
 		WRITE_RTC(0x1, second);
 	}
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/dec/time.c linux/arch/mips/dec/time.c
--- linux-mips/arch/mips/dec/time.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/dec/time.c	2005-09-20 01:39:27.316888200 +0900
@@ -37,10 +37,25 @@
 #include <asm/dec/machtype.h>
 
 
+/*
+ * 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 @@
 	 */
 	/* 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);
@@ -78,6 +94,7 @@
 	 */
 	real_year = CMOS_READ(RTC_DEC_YEAR);
 	year += real_year - 72 + 2000;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
@@ -95,6 +112,8 @@
 	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 @@
 	 */
 	CMOS_WRITE(save_control, RTC_CONTROL);
 	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+	spin_unlock(&rtc_lock);
 
 	return retval;
 }
diff -ur linux-mips/arch/mips/ite-boards/generic/time.c linux/arch/mips/ite-boards/generic/time.c
--- linux-mips/arch/mips/ite-boards/generic/time.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/ite-boards/generic/time.c	2005-09-20 01:39:27.316888200 +0900
@@ -149,15 +149,15 @@
 it8172_rtc_get_time(void)
 {
 	unsigned int year, mon, day, hour, min, sec;
-	unsigned int flags;
+	unsigned long flags;
 
 	/* avoid update-in-progress. */
 	for (;;) {
-		local_irq_save(flags);
+		spin_lock_irqsave(&rtc_lock, flags);
 		if (! (CMOS_READ(RTC_REG_A) & RTC_UIP))
 			break;
 		/* don't hold intr closed all the time */
-		local_irq_restore(flags);
+		spin_unlock_irqrestore(&rtc_lock, flags);
 	}
 
 	/* Read regs. */
@@ -170,7 +170,7 @@
 		hw_to_bin(*rtc_century_reg) * 100;
 
 	/* restore interrupts */
-	local_irq_restore(flags);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
@@ -179,18 +179,18 @@
 it8172_rtc_set_time(unsigned long t)
 {
 	struct rtc_time tm;
-	unsigned int flags;
+	unsigned long flags;
 
 	/* convert */
 	to_tm(t, &tm);
 
 	/* avoid update-in-progress. */
 	for (;;) {
-		local_irq_save(flags);
+		spin_lock_irqsave(&rtc_lock, flags);
 		if (! (CMOS_READ(RTC_REG_A) & RTC_UIP))
 			break;
 		/* don't hold intr closed all the time */
-		local_irq_restore(flags);
+		spin_unlock_irqrestore(&rtc_lock, flags);
 	}
 
 	*rtc_century_reg = bin_to_hw(tm.tm_year/100);
@@ -202,7 +202,7 @@
 	CMOS_WRITE(bin_to_hw(tm.tm_year%100), RTC_YEAR);
 
 	/* restore interrupts */
-	local_irq_restore(flags);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/jmr3927/common/rtc_ds1742.c linux/arch/mips/jmr3927/common/rtc_ds1742.c
--- linux-mips/arch/mips/jmr3927/common/rtc_ds1742.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/jmr3927/common/rtc_ds1742.c	2005-09-20 01:39:27.316888200 +0900
@@ -57,7 +57,9 @@
 {
 	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 @@
 	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 @@
 	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_CENTURY and RTC_CONTROL share same address... */
 	CMOS_WRITE(cmos_century, RTC_CONTROL);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/lasat/ds1603.c linux/arch/mips/lasat/ds1603.c
--- linux-mips/arch/mips/lasat/ds1603.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/lasat/ds1603.c	2005-09-20 01:39:27.317888048 +0900
@@ -8,6 +8,7 @@
 #include <asm/lasat/lasat.h>
 #include <linux/delay.h>
 #include <asm/lasat/ds1603.h>
+#include <asm/time.h>
 
 #include "ds1603.h"
 
@@ -138,19 +139,27 @@
 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 -ur linux-mips/arch/mips/momentum/jaguar_atx/setup.c linux/arch/mips/momentum/jaguar_atx/setup.c
--- linux-mips/arch/mips/momentum/jaguar_atx/setup.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/momentum/jaguar_atx/setup.c	2005-09-20 01:39:27.317888048 +0900
@@ -149,7 +149,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/momentum/ocelot_3/setup.c linux/arch/mips/momentum/ocelot_3/setup.c
--- linux-mips/arch/mips/momentum/ocelot_3/setup.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/momentum/ocelot_3/setup.c	2005-09-20 01:39:27.317888048 +0900
@@ -135,7 +135,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/momentum/ocelot_c/setup.c linux/arch/mips/momentum/ocelot_c/setup.c
--- linux-mips/arch/mips/momentum/ocelot_c/setup.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/momentum/ocelot_c/setup.c	2005-09-20 01:39:27.318887896 +0900
@@ -140,7 +140,9 @@
 	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 @@
 
 	/* 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 @@
 	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 @@
 
 	/* disable writing */
 	rtc_base[0x7ff8] = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/pmc-sierra/yosemite/setup.c linux/arch/mips/pmc-sierra/yosemite/setup.c
--- linux-mips/arch/mips/pmc-sierra/yosemite/setup.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/pmc-sierra/yosemite/setup.c	2005-09-20 01:39:27.318887896 +0900
@@ -73,7 +73,9 @@
 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 @@
 
 	/* 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 @@
 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 @@
 
 	/* disable writing */
 	m48t37_base->control = 0x00;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/sgi-ip22/ip22-time.c linux/arch/mips/sgi-ip22/ip22-time.c
--- linux-mips/arch/mips/sgi-ip22/ip22-time.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/sgi-ip22/ip22-time.c	2005-09-20 01:39:27.359881664 +0900
@@ -35,7 +35,9 @@
 {
 	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 @@
 	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 @@
 {
 	struct rtc_time tm;
 	unsigned int save_control;
+	unsigned long flags;
 
 	to_tm(tim, &tm);
 
@@ -68,6 +72,7 @@
 	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 @@
 	hpc3c0->rtcregs[RTC_HUNDREDTH_SECOND] = 0;
 
 	hpc3c0->rtcregs[RTC_CMD] = save_control;
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
diff -ur linux-mips/arch/mips/sibyte/swarm/rtc_m41t81.c linux/arch/mips/sibyte/swarm/rtc_m41t81.c
--- linux-mips/arch/mips/sibyte/swarm/rtc_m41t81.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/sibyte/swarm/rtc_m41t81.c	2005-09-20 01:39:27.360881512 +0900
@@ -144,6 +144,7 @@
 int m41t81_set_time(unsigned long t)
 {
 	struct rtc_time tm;
+	unsigned long flags;
 
 	to_tm(t, &tm);
 
@@ -153,6 +154,7 @@
 	 * 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 @@
 	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,14 +190,17 @@
 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);
@@ -207,6 +213,7 @@
 	day = BCD2BIN(day);
 	mon = BCD2BIN(mon);
 	year = BCD2BIN(year);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	year += 2000;
 
diff -ur linux-mips/arch/mips/sibyte/swarm/rtc_xicor1241.c linux/arch/mips/sibyte/swarm/rtc_xicor1241.c
--- linux-mips/arch/mips/sibyte/swarm/rtc_xicor1241.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/sibyte/swarm/rtc_xicor1241.c	2005-09-20 01:39:27.361881360 +0900
@@ -113,9 +113,11 @@
 {
 	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 @@
 	xicor_write(X1241REG_HR, tmp);
 
 	xicor_write(X1241REG_SR, 0);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return 0;
 }
@@ -167,7 +170,9 @@
 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 @@
 	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 -ur linux-mips/arch/mips/tx4938/common/rtc_rx5c348.c linux/arch/mips/tx4938/common/rtc_rx5c348.c
--- linux-mips/arch/mips/tx4938/common/rtc_rx5c348.c	2005-09-07 00:26:47.000000000 +0900
+++ linux/arch/mips/tx4938/common/rtc_rx5c348.c	2005-09-20 01:39:27.362881208 +0900
@@ -67,14 +67,20 @@
 {
 	unsigned char *inbufs[1], *outbufs[1];
 	unsigned int incounts[2], outcounts[2];
+	int ret;
+	unsigned long flags;
+
 	inbufs[0] = inbuf;
 	incounts[0] = count;
 	incounts[1] = 0;
 	outbufs[0] = outbuf;
 	outcounts[0] = count;
 	outcounts[1] = 0;
-	return txx9_spi_io(srtc_chipid, &srtc_dev_desc,
-			   inbufs, incounts, outbufs, outcounts, 0);
+	spin_lock_irqsave(&rtc_lock, flags);
+	ret = txx9_spi_io(srtc_chipid, &srtc_dev_desc,
+			  inbufs, incounts, outbufs, outcounts, 0);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+	return ret;
 }
 
 /*
diff -ur linux-mips/include/asm-mips/mc146818-time.h linux/include/asm-mips/mc146818-time.h
--- linux-mips/include/asm-mips/mc146818-time.h	2005-09-07 00:26:47.000000000 +0900
+++ linux/include/asm-mips/mc146818-time.h	2005-09-20 01:39:27.363881056 +0900
@@ -33,7 +33,9 @@
 	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 @@
 	 */
 	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 @@
 
 	/* 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);
@@ -121,6 +140,7 @@
 		BCD_TO_BIN(year);
 	}
 	year = mc146818_decode_year(year);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	return mktime(year, mon, day, hour, min, sec);
 }
diff -ur linux-mips/include/asm-mips/rtc.h linux/include/asm-mips/rtc.h
--- linux-mips/include/asm-mips/rtc.h	2005-09-20 01:32:52.109968784 +0900
+++ linux/include/asm-mips/rtc.h	2005-09-20 01:39:27.366880600 +0900
@@ -14,7 +14,6 @@
 
 #ifdef __KERNEL__
 
-#include <linux/spinlock.h>
 #include <linux/rtc.h>
 #include <asm/time.h>
 
@@ -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 @@
 	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;
 }
diff -ur linux-mips/include/asm-mips/time.h linux/include/asm-mips/time.h
--- linux-mips/include/asm-mips/time.h	2005-09-07 00:26:47.000000000 +0900
+++ linux/include/asm-mips/time.h	2005-09-20 01:39:27.367880448 +0900
@@ -20,6 +20,9 @@
 #include <linux/linkage.h>
 #include <linux/ptrace.h>
 #include <linux/rtc.h>
+#include <linux/spinlock.h>
+
+extern spinlock_t rtc_lock;
 
 /*
  * RTC ops.  By default, they point to no-RTC functions.

From anemo@mba.ocn.ne.jp Mon Sep 19 17:55:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 17:56:11 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:61124 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225352AbVISQzx>; Mon, 19 Sep 2005 17:55:53 +0100
Received: from localhost (p8077-ipad27funabasi.chiba.ocn.ne.jp [220.107.199.77])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id CBBEC46A9; Tue, 20 Sep 2005 01:55:50 +0900 (JST)
Date:	Tue, 20 Sep 2005 01:54:24 +0900 (JST)
Message-Id: <20050920.015424.41632255.anemo@mba.ocn.ne.jp>
To:	ths@networkno.de
Cc:	linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050919154056.GG3386@hattusa.textio>
References: <20050919154056.GG3386@hattusa.textio>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8978
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 583
Lines: 14

>>>>> On Mon, 19 Sep 2005 17:40:56 +0200, Thiemo Seufer <ths@networkno.de> said:

ths> I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
ths> Hit_Writeback_Inv instead of Hit_Invalidate is done. Ralf
ths> mentioned this is probably due to broken Hit_Invalidate cache ops
ths> on some CPUs, does anybody have more information about this? The
ths> appended patch works apparently fine on R4400, R4600v2.0, R5000.

Just a question: Are there any performance advantage of using
Hit_Invalidate instead of Hit_Writeback_Inv if the target line was
CLEAN?

---
Atsushi Nemoto

From macro@linux-mips.org Mon Sep 19 18:01:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 18:01:34 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:27397 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225388AbVISRBQ>; Mon, 19 Sep 2005 18:01:16 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id D6534F59C2; Mon, 19 Sep 2005 19:01:05 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 32695-02; Mon, 19 Sep 2005 19:01:05 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 57E78F59C0; Mon, 19 Sep 2005 19:01:05 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j8JH16gQ000534;
	Mon, 19 Sep 2005 19:01:06 +0200
Date:	Mon, 19 Sep 2005 18:01:16 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <20050919154056.GG3386@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl>
References: <20050919154056.GG3386@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1084/Sat Sep 17 05:32:40 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8979
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 905
Lines: 19

On Mon, 19 Sep 2005, Thiemo Seufer wrote:

> I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> Hit_Writeback_Inv instead of Hit_Invalidate is done. Ralf mentioned
> this is probably due to broken Hit_Invalidate cache ops on some
> CPUs, does anybody have more information about this? The appended
> patch works apparently fine on R4400, R4600v2.0, R5000.

 It's actually been on my to-do list for research for quite a while.  
These functions are called through pointers, so even if there are errata 
in some processors, I'd be more than happy to use pure invalidations for 
these that work whenever possible.

 FYI, for R4k DECstations the need to flush the cache for newly allocated 
skbs reduces throughput of FDDI reception by about a half (!), down from 
about 90Mbps (that's for the /260); hopefully with no writebacks the 
performance hit will be at least a bit smaller.

  Maciej

From ths@networkno.de Mon Sep 19 19:31:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 19:31:48 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:55011 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8225399AbVISSb3>;
	Mon, 19 Sep 2005 19:31:29 +0100
Received: from port-195-158-179-11.dynamic.qsc.de ([195.158.179.11] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1EHQQB-0001y9-00; Mon, 19 Sep 2005 20:31:19 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EHQQA-0004Eu-Rp; Mon, 19 Sep 2005 20:31:18 +0200
Date:	Mon, 19 Sep 2005 20:31:18 +0200
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
Message-ID: <20050919183118.GH3386@hattusa.textio>
References: <20050919154056.GG3386@hattusa.textio> <20050920.015424.41632255.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050920.015424.41632255.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8980
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 687
Lines: 17

Atsushi Nemoto wrote:
> >>>>> On Mon, 19 Sep 2005 17:40:56 +0200, Thiemo Seufer <ths@networkno.de> said:
> 
> ths> I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> ths> Hit_Writeback_Inv instead of Hit_Invalidate is done. Ralf
> ths> mentioned this is probably due to broken Hit_Invalidate cache ops
> ths> on some CPUs, does anybody have more information about this? The
> ths> appended patch works apparently fine on R4400, R4600v2.0, R5000.
> 
> Just a question: Are there any performance advantage of using
> Hit_Invalidate instead of Hit_Writeback_Inv if the target line was
> CLEAN?

I wouldn't think so, but it depends on the particular implementation.


Thiemo

From pf@net.alphadv.de Mon Sep 19 22:35:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Sep 2005 22:35:55 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:65030 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8225534AbVISVfj>; Mon, 19 Sep 2005 22:35:39 +0100
Received: from Snailmail (217.249.192.183)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Mon, 19 Sep 2005 23:32:50 +0200
Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id j8JLWnfc001481
	for <linux-mips@linux-mips.org>; Mon, 19 Sep 2005 23:32:50 +0200
Received: from Indigo2.Peter (localhost [127.0.0.1])
	by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.11-rc3-ip28) with ESMTP id j8JLWndB032611
	for <linux-mips@linux-mips.org>; Mon, 19 Sep 2005 23:32:49 +0200
Received: from localhost (pf@localhost)
	by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id j8JLWn1v032608
	for <linux-mips@linux-mips.org>; Mon, 19 Sep 2005 23:32:49 +0200
Date:	Mon, 19 Sep 2005 19:31:44 +0200 (CEST)
From:	peter fuerst <pf@net.alphadv.de>
To:	linux-mips-bounce@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <20050919154056.GG3386@hattusa.textio>
Message-ID: <Pine.LNX.4.58.0509191912110.14548@Indigo2.Peter>
References: <20050919154056.GG3386@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
ReSent-Date: Mon, 19 Sep 2005 23:32:40 +0200 (CEST)
ReSent-From: peter fuerst <pf@net.alphadv.de>
ReSent-To: linux-mips@linux-mips.org
ReSent-Subject:	Re: Performance bug in c-r4k.c cache handling code
ReSent-Message-ID: <Pine.LNX.4.58.0509192332400.32606@Indigo2.Peter>
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8981
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@net.alphadv.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2095
Lines: 64



Hello,

r4k_dma_cache_wback_inv and r4k_dma_cache_inv always had the same function
body.  With some invocations (on some machine at least ;) this does not only
affect performance, but also is corrupting (dma-)memory, so it had to be
adjusted in the IP28-patches from the beginning.  I had some correspondence
with Ralf about it some months ago. He hesitated to take over this changes
because of the reasons mentioned below. (so btw. IP28 got its own
r10k_dma_cache_inv :)

kind regards

pf


On Mon, 19 Sep 2005, Thiemo Seufer wrote:

> Date: Mon, 19 Sep 2005 17:40:56 +0200
> From: Thiemo Seufer <ths@networkno.de>
> Reply-To: linux-mips-bounce@linux-mips.org
> To: linux-mips@linux-mips.org
> Subject: Performance bug in c-r4k.c cache handling code
>
> Hello All,
>
> I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> Hit_Writeback_Inv instead of Hit_Invalidate is done. Ralf mentioned
> this is probably due to broken Hit_Invalidate cache ops on some
> CPUs, does anybody have more information about this? The appended
> patch works apparently fine on R4400, R4600v2.0, R5000.
>
>
> Thiemo
>
>
> Index: arch/mips/mm/c-r4k.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 c-r4k.c
> --- arch/mips/mm/c-r4k.c	9 Sep 2005 20:26:54 -0000	1.119
> +++ arch/mips/mm/c-r4k.c	19 Sep 2005 15:33:35 -0000
> @@ -685,7 +685,7 @@ static void r4k_dma_cache_inv(unsigned l
>  		a = addr & ~(sc_lsize - 1);
>  		end = (addr + size - 1) & ~(sc_lsize - 1);
>  		while (1) {
> -			flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
> +			invalidate_scache_line(a);	/* Hit_Invalidate_SD */
>  			if (a == end)
>  				break;
>  			a += sc_lsize;
> @@ -702,7 +702,7 @@ static void r4k_dma_cache_inv(unsigned l
>  		a = addr & ~(dc_lsize - 1);
>  		end = (addr + size - 1) & ~(dc_lsize - 1);
>  		while (1) {
> -			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
> +			invalidate_dcache_line(a);	/* Hit_Invalidate_D */
>  			if (a == end)
>  				break;
>  			a += dc_lsize;
>
>

From drow@nevyn.them.org Tue Sep 20 04:28:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 04:28:42 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:39854 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8224833AbVITD2V>;
	Tue, 20 Sep 2005 04:28:21 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EHYnq-0001sR-Rt; Mon, 19 Sep 2005 23:28:18 -0400
Date:	Mon, 19 Sep 2005 23:28:18 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
Message-ID: <20050920032818.GA7199@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8982
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1142
Lines: 30

The type of sum in csum_tcpudp_nofold is "unsigned int", so when we assign
to it in an asm() block, and we're running on a system with 64-bit
registers, it is vitally important that we sign extend it correctly before
returning to C.  Otherwise the stray high bits will be preserved into
csum_fold, and on the SB-1 processor, 32-bit arithmetic on a non
sign-extended register will yield surprising results.

This caused incorrect checksums in some UDP packets for NFS root.  The
problem was mild when using a 10.0.1.x IP address, but severe when
using 192.168.1.x.

Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>

Index: linux/include/asm-mips/checksum.h
===================================================================
--- linux.orig/include/asm-mips/checksum.h	2005-09-19 21:00:48.000000000 -0400
+++ linux/include/asm-mips/checksum.h	2005-09-19 21:52:11.000000000 -0400
@@ -149,7 +149,7 @@ static inline unsigned int csum_tcpudp_n
 	"	daddu	%0, %4		\n"
 	"	dsll32	$1, %0, 0	\n"
 	"	daddu	%0, $1		\n"
-	"	dsrl32	%0, %0, 0	\n"
+	"	dsra32	%0, %0, 0	\n"
 #endif
 	"	.set	pop"
 	: "=r" (sum)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From geert@linux-m68k.org Tue Sep 20 07:04:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 07:04:35 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:4337 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224902AbVITGEN>;
	Tue, 20 Sep 2005 07:04:13 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j8K64Cva024940;
	Tue, 20 Sep 2005 08:04:12 +0200 (MEST)
Date:	Tue, 20 Sep 2005 08:03:56 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Christoph Hellwig <hch@lst.de>
cc:	Ralf Baechle <ralf@linux-mips.org>, Andrew Morton <akpm@osdl.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] switch sibyte profiling driver to ->compat_ioctl
In-Reply-To: <20050919150822.GB13478@lst.de>
Message-ID: <Pine.LNX.4.62.0509200802570.2617@numbat.sonytel.be>
References: <20050919150822.GB13478@lst.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8983
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 901
Lines: 27

On Mon, 19 Sep 2005, Christoph Hellwig wrote:
> --- linux-2.6.orig/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-18 13:46:52.000000000 +0200
> +++ linux-2.6/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-19 15:13:53.000000000 +0200
> @@ -364,7 +366,8 @@
>  	.open		= sbprof_tb_open,
>  	.release	= sbprof_tb_release,
>  	.read		= sbprof_tb_read,
> -	.ioctl		= sbprof_tb_ioctl,
> +	.unlocked_ioctl	= sbprof_tb_ioctl,
> +	.comapt_ioctl	= sbprof_tb_ioctl,
         ^^^^^^^^^^^^
>  	.mmap		= NULL,
>  };

DISCLAIMER: I didn't check whether the spelling error is in the struct
definition as well.

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 hch@lst.de Tue Sep 20 09:06:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 09:06:35 +0100 (BST)
Received: from verein.lst.de ([IPv6:::ffff:213.95.11.210]:46276 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8225198AbVITIGR>;
	Tue, 20 Sep 2005 09:06:17 +0100
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j8K86F6t029020
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 20 Sep 2005 10:06:15 +0200
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id j8K86ErO029018;
	Tue, 20 Sep 2005 10:06:14 +0200
Date:	Tue, 20 Sep 2005 10:06:14 +0200
From:	Christoph Hellwig <hch@lst.de>
To:	Geert Uytterhoeven <geert@linux-m68k.org>
Cc:	Christoph Hellwig <hch@lst.de>, Ralf Baechle <ralf@linux-mips.org>,
	Andrew Morton <akpm@osdl.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] switch sibyte profiling driver to ->compat_ioctl
Message-ID: <20050920080614.GA29000@lst.de>
References: <20050919150822.GB13478@lst.de> <Pine.LNX.4.62.0509200802570.2617@numbat.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.62.0509200802570.2617@numbat.sonytel.be>
User-Agent: Mutt/1.3.28i
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8984
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 740
Lines: 20

On Tue, Sep 20, 2005 at 08:03:56AM +0200, Geert Uytterhoeven wrote:
> On Mon, 19 Sep 2005, Christoph Hellwig wrote:
> > --- linux-2.6.orig/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-18 13:46:52.000000000 +0200
> > +++ linux-2.6/arch/mips/sibyte/sb1250/bcm1250_tbprof.c	2005-09-19 15:13:53.000000000 +0200
> > @@ -364,7 +366,8 @@
> >  	.open		= sbprof_tb_open,
> >  	.release	= sbprof_tb_release,
> >  	.read		= sbprof_tb_read,
> > -	.ioctl		= sbprof_tb_ioctl,
> > +	.unlocked_ioctl	= sbprof_tb_ioctl,
> > +	.comapt_ioctl	= sbprof_tb_ioctl,
>          ^^^^^^^^^^^^
> >  	.mmap		= NULL,
> >  };
> 
> DISCLAIMER: I didn't check whether the spelling error is in the struct
> definition as well.

no, it's not.  thanks for catching it :)


From jerry@wicomtechnologies.com Tue Sep 20 09:20:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 09:20:33 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:47328
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225198AbVITIUL>; Tue, 20 Sep 2005 09:20:11 +0100
Received: from [192.168.0.24] (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j8K8K1NC059324
	for <linux-mips@linux-mips.org>; Tue, 20 Sep 2005 11:20:01 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Tue, 20 Sep 2005 11:19:57 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.51.10) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <477557788.20050920111957@wicomtechnologies.com>
To:	"ppopov@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050920002016Z8225531-3678+9789@linux-mips.org>
References: <20050920002016Z8225531-3678+9789@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8985
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips
Content-Length: 616
Lines: 17

>[In reply to "CVS Update@linux-mips.org: linux" from ppopov@linux-mips.org <ppopov@linux-mips.org> to linux-cvs@linux-mips.org <linux-cvs@linux-mips.org>  20.09.2005 3:20]

> Log message:
>         Au1200 fb driver. Updated db1200 defconfig to include driver by
>         default.

Looks like a some early versions. Anyway good news that i'is in the
tree. The bad news that it mostly unusable and needs a lot of work.
(I don't think one can use it with IOCTL code defined in .c file :) )

All society now waits for mae driver.


   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.51.10>- -<20.09.2005 11:11>-
  (") (")


From dom@mips.com Tue Sep 20 10:10:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 10:10:17 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:54285 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225283AbVITJKB>;
	Tue, 20 Sep 2005 10:10:01 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EHe6l-00081J-00; Tue, 20 Sep 2005 10:08:11 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EHe7r-0001Xd-00; Tue, 20 Sep 2005 10:09:19 +0100
From:	Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17199.53696.27856.801284@mips.com>
Date:	Tue, 20 Sep 2005 10:09:20 +0100
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl>
References: <20050919154056.GG3386@hattusa.textio>
	<Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl>
X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.826,
	required 4, AWL, BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8986
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1690
Lines: 38


> > I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> > Hit_Writeback_Inv instead of Hit_Invalidate is done.

The MIPS64 spec (which is really all there is to set standards in this
area) regards Hit_Invalidate as optional.  So it would be nice not to
use it.  CPUs have no standard "configuration" register you can read
to establish which cacheops work, so to identify capable CPUs you must
use a table of CPU attributes indexed by the CPU ID, which encourages
the crime of building software which can't possibly run on a new CPU...

So long as the buffer is in fact clean, then in most implementations a
Hit_Writeback_Invalidate will be just as efficient.

Moreover, CPUs always "post" writes to some extent, so a small
percentage of dirty lines can be handled without any great overhead.
So a significant advantage can only occur when the buffer you want to
invalidate (prior to DMA-in) was fairly recently densely written by
the CPU; and this is only safe when all that data can be guaranteed to
now be of no importance to anyone.

Randomly and retrospectively discarding writes could generate some
very interesting bugs, or (indeed) usually hide some very interesting
bugs.  It's the kind of thing one would lik to avoid!

I suppose where DMA data subsequently gets decorated by the CPU then
handed on to some other layer, then the buffer is freed...?

> FYI, for R4k DECstations the need to flush the cache for newly allocated 
> skbs reduces throughput of FDDI reception by about a half (!), down from 
> about 90Mbps (that's for the /260)...

How did you measure the high throughput?  Have you got a
machine with DMA-coherency you can turn on and off?

--
Dominic


From ihollo@tom.com Tue Sep 20 10:14:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 10:14:28 +0100 (BST)
Received: from smtpr2.tom.com ([IPv6:::ffff:202.108.255.197]:20719 "HELO
	tom.com") by linux-mips.org with SMTP id <S8225198AbVITJOK>;
	Tue, 20 Sep 2005 10:14:10 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp3 (Coremail) with SMTP id PAAxZN_SL0MeACac.1
	for <linux-mips@linux-mips.org>; Tue, 20 Sep 2005 17:14:09 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <432FD2DF.1070506@tom.com>
Date:	Tue, 20 Sep 2005 17:14:07 +0800
From:	Zhuang Yuyao <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: [A little bit offtopic] AU1550 board ODM
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Return-Path: <ihollo@tom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8987
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ihollo@tom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1602
Lines: 45

(3 times I tried to send this mail, but it does not appear in the list,
If the content of this mail violates the policy of this maillist, please
let me know and I'd apologize)

Hi,

We (a Chinese company) are looking for a board design based on AMD
au1550.  We would like to pay $2500~$5000 (in US dollar) for a board
design which fits our requirements.

Some brief requirements:
1) 6 10/100Mbit ethernet ports, any one of them should be able to
configured to have its own IP address. (sorry for bad english, I mean
some thing like this (http://www.linux-mips.org/wiki/ADM5120_switch));
2) at least 1 mini-pci slot, 2 is preferred;
3) RAM (DDR) can be configured to 64M, 128M and 256M
4) Flash (NAND): 64M
5) IDE connection (including power) for 2.5inch notebook hard disk.
6) Bootloader and Safenet encryption engine support. (OS: linux 2.6.x)
7) 4-layers PCB is preferred.

Desired hardware and files:
1) Schematics file for this board
2) BOM from the board
3) PADS layout files
4) PCB gerber files
5) 2 Prototype boards

Desired Software:
1) Bootloader source code, (the original Yamon and the patches)
2) A demo kernel and root file system (Linux 2.6.x, uClibc) for this
board.

If anyone is interested in this, please contact me with the email
address provided below. An ODM contract will be signed after all the
details are discussed and settled. In case you are worried about the
credit of us, I will contact AMD office in Shanghai and make AMD the
supervisor/broker for this case.

Thanks in advance.

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhuang Yuyao
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ihollo@tom.com
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-09-18


From macro@linux-mips.org Tue Sep 20 11:43:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 11:43:43 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:48142 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225198AbVITKn1>; Tue, 20 Sep 2005 11:43:27 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 48991F596A; Tue, 20 Sep 2005 12:43:23 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 27059-02; Tue, 20 Sep 2005 12:43:23 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id C0557F5969; Tue, 20 Sep 2005 12:43:22 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j8KAhL1q001223;
	Tue, 20 Sep 2005 12:43:22 +0200
Date:	Tue, 20 Sep 2005 11:43:27 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
In-Reply-To: <20050920032818.GA7199@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0509201140160.23494@blysk.ds.pg.gda.pl>
References: <20050920032818.GA7199@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1090/Mon Sep 19 23:29:31 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8988
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 373
Lines: 11

On Mon, 19 Sep 2005, Daniel Jacobowitz wrote:

> This caused incorrect checksums in some UDP packets for NFS root.  The
> problem was mild when using a 10.0.1.x IP address, but severe when
> using 192.168.1.x.

 Ah!  So *that* is the reason for the absolutely abysmal NFS performance 
of the SWARM with 2.6!  I have had no time to track it down -- thanks a 
lot!

  Maciej

From matej.kupljen@ultra.si Tue Sep 20 12:00:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 12:00:34 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:2467 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225294AbVITLAO>; Tue, 20 Sep 2005 12:00:14 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 81C15C024;
	Tue, 20 Sep 2005 13:00:05 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id 2F9451BC08C;
	Tue, 20 Sep 2005 13:00:08 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id B80BB1A18B0;
	Tue, 20 Sep 2005 13:00:07 +0200 (CEST)
Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	ralf@linux-mips.org
In-Reply-To: <Pine.LNX.4.61L.0509201140160.23494@blysk.ds.pg.gda.pl>
References: <20050920032818.GA7199@nevyn.them.org>
	 <Pine.LNX.4.61L.0509201140160.23494@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Date:	Tue, 20 Sep 2005 13:00:04 +0200
Message-Id: <1127214005.2149.15.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8989
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 431
Lines: 16

Hi

> > This caused incorrect checksums in some UDP packets for NFS root.  The
> > problem was mild when using a 10.0.1.x IP address, but severe when
> > using 192.168.1.x.
> 
>  Ah!  So *that* is the reason for the absolutely abysmal NFS performance 
> of the SWARM with 2.6!  I have had no time to track it down -- thanks a 
> lot!

Is this for MIPS64 only?
Because, on dbau1200 we also have poor NFS performance :-(

BR,
Matej


From ralf@linux-mips.org Tue Sep 20 12:01:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 12:01:30 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:39443 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225348AbVITLBK>; Tue, 20 Sep 2005 12:01:10 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8KB12iU005125;
	Tue, 20 Sep 2005 12:01:02 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8KB12i2005114;
	Tue, 20 Sep 2005 12:01:02 +0100
Date:	Tue, 20 Sep 2005 12:01:02 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
Message-ID: <20050920110101.GA3159@linux-mips.org>
References: <20050920032818.GA7199@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050920032818.GA7199@nevyn.them.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8990
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 753
Lines: 17

On Mon, Sep 19, 2005 at 11:28:18PM -0400, Daniel Jacobowitz wrote:

> The type of sum in csum_tcpudp_nofold is "unsigned int", so when we assign
> to it in an asm() block, and we're running on a system with 64-bit
> registers, it is vitally important that we sign extend it correctly before
> returning to C.  Otherwise the stray high bits will be preserved into
> csum_fold, and on the SB-1 processor, 32-bit arithmetic on a non
> sign-extended register will yield surprising results.
> 
> This caused incorrect checksums in some UDP packets for NFS root.  The
> problem was mild when using a 10.0.1.x IP address, but severe when
> using 192.168.1.x.

Good catch.  And just to increase the func factor this bug did also apply
to 2.4.  Applied,

  Ralf

From ralf@linux-mips.org Tue Sep 20 12:06:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 12:06:38 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:51728 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225348AbVITLGQ>; Tue, 20 Sep 2005 12:06:16 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8KB69uQ005289;
	Tue, 20 Sep 2005 12:06:09 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8KB69Z3005288;
	Tue, 20 Sep 2005 12:06:09 +0100
Date:	Tue, 20 Sep 2005 12:06:09 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Matej Kupljen <matej.kupljen@ultra.si>
Cc:	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
Message-ID: <20050920110609.GB3159@linux-mips.org>
References: <20050920032818.GA7199@nevyn.them.org> <Pine.LNX.4.61L.0509201140160.23494@blysk.ds.pg.gda.pl> <1127214005.2149.15.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1127214005.2149.15.camel@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8991
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 777
Lines: 20

On Tue, Sep 20, 2005 at 01:00:04PM +0200, Matej Kupljen wrote:

> > > This caused incorrect checksums in some UDP packets for NFS root.  The
> > > problem was mild when using a 10.0.1.x IP address, but severe when
> > > using 192.168.1.x.
> > 
> >  Ah!  So *that* is the reason for the absolutely abysmal NFS performance 
> > of the SWARM with 2.6!  I have had no time to track it down -- thanks a 
> > lot!
> 
> Is this for MIPS64 only?
> Because, on dbau1200 we also have poor NFS performance :-(

It's for 64-bit kernels only.  Note the difference, I didn't say MIPS64.

Also, since this bug did result in an operation that has undefined
behaviour it likely may will only have impacted some 64-bit processors -
such as the SB1 - but others may have been unaffected.

  Ralf

From ralf@linux-mips.org Tue Sep 20 12:23:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 12:24:21 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:3335 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225198AbVITLX6>; Tue, 20 Sep 2005 12:23:58 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8KBNpDq006413;
	Tue, 20 Sep 2005 12:23:51 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8KBNoNT006412;
	Tue, 20 Sep 2005 12:23:50 +0100
Date:	Tue, 20 Sep 2005 12:23:50 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Zhuang Yuyao <ihollo@tom.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: [A little bit offtopic] AU1550 board ODM
Message-ID: <20050920112349.GD3159@linux-mips.org>
References: <432FD2DF.1070506@tom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <432FD2DF.1070506@tom.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8992
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1053
Lines: 23

On Tue, Sep 20, 2005 at 05:14:07PM +0800, Zhuang Yuyao wrote:

> (3 times I tried to send this mail, but it does not appear in the list,
> If the content of this mail violates the policy of this maillist, please
> let me know and I'd apologize)

The list has a spam filter that's configured brutally hard - but given
it's address it so well known that's absolutly needed to keep it from
being ended up knee deep in spam.

If you have a mail that didn't make it feel free to mail me the message id
of the lost email in private and I'll try to find where it did end up.
Without knowing the message id it's often not possible to resolve this
kind of problem.  Or alternatively, if you got a bounce just forward that
bouce to me privately - not the list.

I don't try to enforce any policy for this or any other list that I'm
running other than keeping it free of spam, malware and postings that
obviously have no business of making it to the lists' audience such as
bounces, automated answers, mails that were intended to go to the list
robot etc.

  Ralf

From ralf@linux-mips.org Tue Sep 20 13:22:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 13:23:07 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:52509 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225410AbVITMWu>; Tue, 20 Sep 2005 13:22:50 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8KCMi3p008283;
	Tue, 20 Sep 2005 13:22:44 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8KCMhEf008282;
	Tue, 20 Sep 2005 13:22:43 +0100
Date:	Tue, 20 Sep 2005 13:22:43 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Dominic Sweetman <dom@mips.com>
Cc:	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
Message-ID: <20050920122243.GE3159@linux-mips.org>
References: <20050919154056.GG3386@hattusa.textio> <Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl> <17199.53696.27856.801284@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17199.53696.27856.801284@mips.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8993
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2917
Lines: 64

On Tue, Sep 20, 2005 at 10:09:20AM +0100, Dominic Sweetman wrote:

> > > I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> > > Hit_Writeback_Inv instead of Hit_Invalidate is done.
> 
> The MIPS64 spec (which is really all there is to set standards in this
> area) regards Hit_Invalidate as optional.  So it would be nice not to
> use it.  CPUs have no standard "configuration" register you can read
> to establish which cacheops work, so to identify capable CPUs you must
> use a table of CPU attributes indexed by the CPU ID, which encourages
> the crime of building software which can't possibly run on a new CPU...
> 
> So long as the buffer is in fact clean, then in most implementations a
> Hit_Writeback_Invalidate will be just as efficient.

This are R4700 numbers, the only I was able to find in a quick search.

  Hit_Invalidate_D		 7 cycles for a cache miss
				 9 cycles for a cache hit
  Hit_Writeback_Invalidate_D	 7 cycles for a cache miss
				12 cycles for a cache hit if the cache line
				   is clean.
				14 cycles for a cache hit if the cache line
				   is dirty (Writeback).
  Hit_Writeback_D		 7 cycles for a cache miss
				10 cycles for a cache hit if the cache line
				   is clean
				14 cycles for a cache hit if the cache line
				   is dirty (Writeback).

> Moreover, CPUs always "post" writes to some extent, so a small
> percentage of dirty lines can be handled without any great overhead.
> So a significant advantage can only occur when the buffer you want to
> invalidate (prior to DMA-in) was fairly recently densely written by
> the CPU; and this is only safe when all that data can be guaranteed to
> now be of no importance to anyone.

Linux has a well-defined ABI that DMA drivers are supposed to use; the
functions of this ABI that perform cache flushes also take a DMA
direction argument based on which the implementation can deciede on what
the best flush function for a particular case will be.

> Randomly and retrospectively discarding writes could generate some
> very interesting bugs, or (indeed) usually hide some very interesting
> bugs.  It's the kind of thing one would lik to avoid!
> 
> I suppose where DMA data subsequently gets decorated by the CPU then
> handed on to some other layer, then the buffer is freed...?
> 
> > FYI, for R4k DECstations the need to flush the cache for newly allocated 
> > skbs reduces throughput of FDDI reception by about a half (!), down from 
> > about 90Mbps (that's for the /260)...

Software coherency will result in many server / client type operations
approximate worst case as none of the data will reside in caches.  Routers
are going to be somewhat better off - as long as they don't peek to deep
into the packets, that is.

> How did you measure the high throughput?  Have you got a
> machine with DMA-coherency you can turn on and off?

Afaik AMD Alchemy processors have configurable coherency.

  Ralf

From macro@linux-mips.org Tue Sep 20 13:37:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 13:37:47 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:776 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225410AbVITMhc>; Tue, 20 Sep 2005 13:37:32 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id BE557F596C; Tue, 20 Sep 2005 14:37:27 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 28365-02; Tue, 20 Sep 2005 14:37:27 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 4C415F5969; Tue, 20 Sep 2005 14:37:27 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j8KCbQ0f006073;
	Tue, 20 Sep 2005 14:37:26 +0200
Date:	Tue, 20 Sep 2005 13:37:33 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Dominic Sweetman <dom@mips.com>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <17199.53696.27856.801284@mips.com>
Message-ID: <Pine.LNX.4.61L.0509201017220.23494@blysk.ds.pg.gda.pl>
References: <20050919154056.GG3386@hattusa.textio>
 <Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl> <17199.53696.27856.801284@mips.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1090/Mon Sep 19 23:29:31 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8994
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2577
Lines: 52

On Tue, 20 Sep 2005, Dominic Sweetman wrote:

> > > I found an performance bug in c-r4k.c:r4k_dma_cache_inv, where a
> > > Hit_Writeback_Inv instead of Hit_Invalidate is done.
> 
> The MIPS64 spec (which is really all there is to set standards in this
> area) regards Hit_Invalidate as optional.  So it would be nice not to
> use it.  CPUs have no standard "configuration" register you can read
> to establish which cacheops work, so to identify capable CPUs you must
> use a table of CPU attributes indexed by the CPU ID, which encourages
> the crime of building software which can't possibly run on a new CPU...

 Or just using the safe fallback -- that shouldn't be a problem (these 
functions are called indirectly).  Besides new CPUs more often than not 
require changes to kernel-level software anyway.

> So long as the buffer is in fact clean, then in most implementations a
> Hit_Writeback_Invalidate will be just as efficient.

 I hope so, but who knows what's wired there in all those old systems?...

> I suppose where DMA data subsequently gets decorated by the CPU then
> handed on to some other layer, then the buffer is freed...?

 I don't think the buffer is modified, so cache lines should remain clean. 
For the usual case of IP data is used exactly once for copy_and_csum() 
(more or less) which moves it to another buffer.

> > FYI, for R4k DECstations the need to flush the cache for newly allocated 
> > skbs reduces throughput of FDDI reception by about a half (!), down from 
> > about 90Mbps (that's for the /260)...
> 
> How did you measure the high throughput?  Have you got a
> machine with DMA-coherency you can turn on and off?

 I just disabled invalidations. ;-)  Yes, that resulted in some corrupt 
data, but it was good enough to do benchmarking.  That was an R4400 with 
1MB of S-cache.

 Eventually I should benchmark both invalidation variations against each 
other with the system in question and see if it makes any difference.  
Ironically this is where the write-back cache of the R4k gives loss rather 
than gain as compared to the write-through cache of the R3k (the system 
supports daughtercards with either CPU, so useful comparison is possible) 
as for the former I have to invalidate cache spanning the whole 
newly-allocated buffer, i.e. ~4.5kB, while for the latter I may invalidate 
only the area actually used, once a frame has been received, its length is 
known and quite often much smaller than the maximum (especially if it's 
been routed from a network that has a smaller frame length limit, like 
Ethernet).

  Maciej

From dom@mips.com Tue Sep 20 14:19:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 14:19:53 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:43274 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225417AbVITNTg>;
	Tue, 20 Sep 2005 14:19:36 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EHi0I-0002Ze-00; Tue, 20 Sep 2005 14:17:46 +0100
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EHi1A-0008Ds-00; Tue, 20 Sep 2005 14:18:40 +0100
From:	Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17200.3119.436273.291080@gargle.gargle.HOWL>
Date:	Tue, 20 Sep 2005 14:18:39 +0100
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Dominic Sweetman <dom@mips.com>, Thiemo Seufer <ths@networkno.de>,
	linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <Pine.LNX.4.61L.0509201017220.23494@blysk.ds.pg.gda.pl>
References: <20050919154056.GG3386@hattusa.textio>
	<Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl>
	<17199.53696.27856.801284@mips.com>
	<Pine.LNX.4.61L.0509201017220.23494@blysk.ds.pg.gda.pl>
X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.827,
	required 4, AWL, BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8995
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2210
Lines: 56


Maciej W. Rozycki (macro@linux-mips.org) writes:

> Besides new CPUs more often than not 
> require changes to kernel-level software anyway.

Making sure that isn't so is the reason why there's a MIPS32/64 spec
(with all the privileged operations defined).  Which also avoids the
undesirable development step of new hardware combined with new kernel
software... 

> > How did you measure the high throughput?  Have you got a
> > machine with DMA-coherency you can turn on and off?
> 
>  I just disabled invalidations. ;-)

Ouch.  So the effect could have come from a variety of sources.

> That was an R4400 with 1MB of S-cache.

With an R4400 S-cache, any difference between "would write it back but
it's clean" and "just invalidate" is likely to be small, since in
either case the time will be dominated by the (external) cache tag
memory RMW operation.

> Eventually I should benchmark both invalidation variations against each 
> other with the system in question and see if it makes any difference.  

Indeed.  And it might also be a good idea to test a more modern
system, too, to see how big an effect this might be.

> Ironically this is where the write-back cache of the R4k gives loss
> rather than gain as compared to the write-through cache of the R3k
> (the system supports daughtercards with either CPU, so useful
> comparison is possible)...

Maybe.  But remember, on the R3K every write was a write through, and
they all had a cost in bus congestion, which may have delayed a
following read and held up the CPU (or the write buffer may have
filled and stalled the CPU). 

I think up to about 33MHz write-through remained a tolerable policy
for 1988-era memory systems; any faster than that and you just sank
under a flood of writes.  2005-era memory systems are much faster when
bursting, but the time they take to process a single write cycle has
improved by less than 2x.  So write-through is still a really bad idea
for 100MHz CPUs using off-chip memory.

Even when your device requires you to push out all the data it can be
more efficient to write data to the cache and then force writeback to
memory: at least that way the data goes to the memory in efficient
burst cycles.

--
Dominic


From uhler@mips.com Tue Sep 20 15:27:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 15:27:34 +0100 (BST)
Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:12679
	"EHLO dns0.mips.com") by linux-mips.org with ESMTP
	id <S8224903AbVITO1M>; Tue, 20 Sep 2005 15:27:12 +0100
Received: from mercury.mips.com (sbcns-dmz [209.232.97.193])
	by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j8KEQw6U004993;
	Tue, 20 Sep 2005 07:26:58 -0700 (PDT)
Received: from laptopuhler4 (laptop-uhler4.mips.com [192.168.2.3])
	by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j8KEQs17013302;
	Tue, 20 Sep 2005 07:26:58 -0700 (PDT)
From:	"Michael Uhler" <uhler@mips.com>
To:	"'Ralf Baechle'" <ralf@linux-mips.org>,
	"'Matej Kupljen'" <matej.kupljen@ultra.si>
Cc:	"'Maciej W. Rozycki'" <macro@linux-mips.org>,
	"'Daniel Jacobowitz'" <dan@debian.org>, <linux-mips@linux-mips.org>
Subject: RE: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
Date:	Tue, 20 Sep 2005 07:26:54 -0700
Organization: MIPS Technologies, Inc.
Message-ID: <00da01c5bdef$596ee380$0502a8c0@MIPS.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <20050920110609.GB3159@linux-mips.org>
X-Scanned-By: MIMEDefang 2.39
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8996
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1612
Lines: 51

For what it's worth, the 64-bit architecture, both prior to and with MIPS64,
has always required that 64-bit GPRs be sign-extended when used with 32-bit
operations.  I'm surprised that this wasn't seen on more 64-bit CPUs than
just the SB1.


/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler at mips.com
1225 Charleston Road      Voice:  (650)567-5025
Mountain View, CA 94043

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle
> Sent: Tuesday, September 20, 2005 4:06 AM
> To: Matej Kupljen
> Cc: Maciej W. Rozycki; Daniel Jacobowitz; linux-mips@linux-mips.org
> Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
> 
> 
> On Tue, Sep 20, 2005 at 01:00:04PM +0200, Matej Kupljen wrote:
> 
> > > > This caused incorrect checksums in some UDP packets for 
> NFS root.  
> > > > The problem was mild when using a 10.0.1.x IP address, 
> but severe 
> > > > when using 192.168.1.x.
> > > 
> > >  Ah!  So *that* is the reason for the absolutely abysmal NFS 
> > > performance
> > > of the SWARM with 2.6!  I have had no time to track it 
> down -- thanks a 
> > > lot!
> > 
> > Is this for MIPS64 only?
> > Because, on dbau1200 we also have poor NFS performance :-(
> 
> It's for 64-bit kernels only.  Note the difference, I didn't 
> say MIPS64.
> 
> Also, since this bug did result in an operation that has 
> undefined behaviour it likely may will only have impacted 
> some 64-bit processors - such as the SB1 - but others may 
> have been unaffected.
> 
>   Ralf
> 
> 


From macro@linux-mips.org Tue Sep 20 15:50:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 15:51:20 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:37134 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224903AbVITOu7>; Tue, 20 Sep 2005 15:50:59 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 3310EF5978; Tue, 20 Sep 2005 16:50:52 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 15158-02; Tue, 20 Sep 2005 16:50:52 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id B4997F5977; Tue, 20 Sep 2005 16:50:51 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j8KEoqh1011229;
	Tue, 20 Sep 2005 16:50:52 +0200
Date:	Tue, 20 Sep 2005 15:51:01 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Dominic Sweetman <dom@mips.com>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Performance bug in c-r4k.c cache handling code
In-Reply-To: <17200.3119.436273.291080@gargle.gargle.HOWL>
Message-ID: <Pine.LNX.4.61L.0509201451520.23494@blysk.ds.pg.gda.pl>
References: <20050919154056.GG3386@hattusa.textio>
 <Pine.LNX.4.61L.0509191733180.5551@blysk.ds.pg.gda.pl> <17199.53696.27856.801284@mips.com>
 <Pine.LNX.4.61L.0509201017220.23494@blysk.ds.pg.gda.pl>
 <17200.3119.436273.291080@gargle.gargle.HOWL>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/1091/Tue Sep 20 15:59:01 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8997
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2771
Lines: 60

On Tue, 20 Sep 2005, Dominic Sweetman wrote:

> > Besides new CPUs more often than not 
> > require changes to kernel-level software anyway.
> 
> Making sure that isn't so is the reason why there's a MIPS32/64 spec
> (with all the privileged operations defined).  Which also avoids the
> undesirable development step of new hardware combined with new kernel
> software... 

 Except that clairvoyance does not work reliably in the long run, so while 
you may be able to run old software with no changes on a new chip using a 
subset of its capabilities, you probably still want to update your kernel 
to better exploit the new design.

> >  I just disabled invalidations. ;-)
> 
> Ouch.  So the effect could have come from a variety of sources.

 Yes, I should have probably really done a better arrangement -- but I had 
limited time for testing, so I did just a rough estimate.  I should get 
back to it eventually as that piece of code requires further tuning.

> > Ironically this is where the write-back cache of the R4k gives loss
> > rather than gain as compared to the write-through cache of the R3k
> > (the system supports daughtercards with either CPU, so useful
> > comparison is possible)...
> 
> Maybe.  But remember, on the R3K every write was a write through, and
> they all had a cost in bus congestion, which may have delayed a
> following read and held up the CPU (or the write buffer may have
> filled and stalled the CPU). 

 Effective bandwidth of DRAM memory for the system is documented to be 
100MB/s and the R3k used (the PACEMIPS R3400) is clocked @40MHz (the R4400 
on the other daughterboard is clocked @60MHz).  Therefore while I believe 
congestion is indeed possible, it's not really that common with PIO, 
especially as the CPU has a priority over DMA traffic.  Except from 
partial word writes which require RMW cycles at the memory controller 
level due to ECC (but they are not used for bulk transfers anyway).

> I think up to about 33MHz write-through remained a tolerable policy
> for 1988-era memory systems; any faster than that and you just sank
> under a flood of writes.  2005-era memory systems are much faster when
> bursting, but the time they take to process a single write cycle has
> improved by less than 2x.  So write-through is still a really bad idea
> for 100MHz CPUs using off-chip memory.

 Certainly.  It's just systems with a lot of DMA traffic do really beg for 
hardware-maintained coherence.

> Even when your device requires you to push out all the data it can be
> more efficient to write data to the cache and then force writeback to
> memory: at least that way the data goes to the memory in efficient
> burst cycles.

 That's assuming cache does write-allocation, which is not always the 
case.

  Maciej

From ppopov@embeddedalley.com Tue Sep 20 15:53:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 15:54:12 +0100 (BST)
Received: from smtp102.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.237]:21182
	"HELO smtp102.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8224903AbVITOxw>; Tue, 20 Sep 2005 15:53:52 +0100
Received: (qmail 5629 invoked from network); 20 Sep 2005 14:53:44 -0000
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp102.biz.mail.mud.yahoo.com with SMTP; 20 Sep 2005 14:53:44 -0000
Subject: Re: CVS Update@linux-mips.org: linux
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Jerry <jerry@wicomtechnologies.com>
Cc:	"ppopov@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <477557788.20050920111957@wicomtechnologies.com>
References: <20050920002016Z8225531-3678+9789@linux-mips.org>
	 <477557788.20050920111957@wicomtechnologies.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 20 Sep 2005 07:53:48 -0700
Message-Id: <1127228028.4948.228.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8998
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 803
Lines: 19

On Tue, 2005-09-20 at 11:19 +0300, Jerry wrote:
> >[In reply to "CVS Update@linux-mips.org: linux" from ppopov@linux-mips.org <ppopov@linux-mips.org> to linux-cvs@linux-mips.org <linux-cvs@linux-mips.org>  20.09.2005 3:20]
> 
> > Log message:
> >         Au1200 fb driver. Updated db1200 defconfig to include driver by
> >         default.
> 
> Looks like a some early versions. Anyway good news that i'is in the
> tree. The bad news that it mostly unusable and needs a lot of work.
> (I don't think one can use it with IOCTL code defined in .c file :) )

What's mostly unusable? I only did cosmetic cleanups of this one and
gave it a quick test. Seemed to work fine. Let me know what you've
tested and didn't work for you and we'll fix it at some point.

> All society now waits for mae driver.

Pete


From ralf@linux-mips.org Tue Sep 20 16:00:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 16:00:27 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:33558 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225202AbVITPAA>; Tue, 20 Sep 2005 16:00:00 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8KExroO013859;
	Tue, 20 Sep 2005 15:59:53 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8KExm3e013832;
	Tue, 20 Sep 2005 15:59:48 +0100
Date:	Tue, 20 Sep 2005 15:59:48 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Michael Uhler <uhler@mips.com>
Cc:	"'Matej Kupljen'" <matej.kupljen@ultra.si>,
	"'Maciej W. Rozycki'" <macro@linux-mips.org>,
	"'Daniel Jacobowitz'" <dan@debian.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH] Fix TCP/UDP checksums on the Broadcom SB-1
Message-ID: <20050920145948.GF3159@linux-mips.org>
References: <20050920110609.GB3159@linux-mips.org> <00da01c5bdef$596ee380$0502a8c0@MIPS.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00da01c5bdef$596ee380$0502a8c0@MIPS.COM>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 8999
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 667
Lines: 14

On Tue, Sep 20, 2005 at 07:26:54AM -0700, Michael Uhler wrote:

> For what it's worth, the 64-bit architecture, both prior to and with MIPS64,
> has always required that 64-bit GPRs be sign-extended when used with 32-bit
> operations.  I'm surprised that this wasn't seen on more 64-bit CPUs than
> just the SB1.

Usually resends will paper over this kind of problem.  It's only a question
of time until they succeed for any protocol that changed the packet
content sufficiently to make the checksum work eventually.  But of course
performance will suffer and as a matter of statistics certain IP address
and port ranges are going to suffer more than others.

  Ralf

From jerry@wicomtechnologies.com Tue Sep 20 16:34:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 16:34:32 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([IPv6:::ffff:195.234.214.162]:13793
	"EHLO smtp.wicomtechnologies.com") by linux-mips.org with ESMTP
	id <S8225202AbVITPeN>; Tue, 20 Sep 2005 16:34:13 +0100
Received: from [192.168.0.24] (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j8KFY1NC060633;
	Tue, 20 Sep 2005 18:34:01 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Tue, 20 Sep 2005 18:33:57 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.51.10) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <622539804.20050920183357@wicomtechnologies.com>
To:	Pete Popov <ppopov@embeddedalley.com>
CC:	linux-mips@linux-mips.org
Subject: Re[2]: CVS Update@linux-mips.org: linux
In-Reply-To: <1127228028.4948.228.camel@localhost.localdomain>
References: <20050920002016Z8225531-3678+9789@linux-mips.org>
 <477557788.20050920111957@wicomtechnologies.com>
 <1127228028.4948.228.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9000
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1519
Lines: 32

>[In reply to "CVS Update@linux-mips.org: linux" from Pete Popov <ppopov@embeddedalley.com> to Jerry <jerry@wicomtechnologies.com>  20.09.2005 17:53]

> What's mostly unusable? I only did cosmetic cleanups of this one and
> gave it a quick test. Seemed to work fine. Let me know what you've
> tested and didn't work for you and we'll fix it at some point.

Generic fb may work (but some months ago I tested earlier version for
2.4 and it fails on most graphic tests (I used tests for SDL)). It
grows up, and this version may work well with base fb, but au1200 has
some advances and all its specifics controls through ioctl. Ioctl code
#defined in driver's .c source (hehe) it's very unusual way :) There's
no header file to work with the driver from kernel/userspace.

Driver has it's own mmap implementation but it left from au1100 driver
where it controlled ...cache lines. In au1200 it does noting unusual
and actually is a copy of generic fb mmap from kernel. One can remove
au1200_fb_mmap to use standart func to mmap memory but it needs to
properly set fix.mmio_start and family to work properly...

It has a CRT but cannot change videomodes.. etc ..etc

In short, if you'll work with device, all this little invisible things
will shown up.. But again, as base console fb it may work well.

Pity, about a month ago we suspended our au1200 project for some
months. Hope I will able to help with driver when we'll continue it.


   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.51.10>- -<20.09.2005 17:57>-
  (") (")


From ppopov@embeddedalley.com Tue Sep 20 20:45:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 20:46:05 +0100 (BST)
Received: from smtp102.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.237]:52356
	"HELO smtp102.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225377AbVITTpr>; Tue, 20 Sep 2005 20:45:47 +0100
Received: (qmail 81429 invoked from network); 20 Sep 2005 19:45:37 -0000
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp102.biz.mail.mud.yahoo.com with SMTP; 20 Sep 2005 19:45:36 -0000
Subject: stale board ports, again
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 20 Sep 2005 12:45:42 -0700
Message-Id: <1127245542.4948.269.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9001
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 176
Lines: 9


Is there anyone using the mtx-1, csb250, or xxs1500 in 2.6? If so, how
badly broken are they and does anyone want to maintain them or is it
time to nuke them?

Thanks,

Pete


From bruno.randolf@4g-systems.biz Tue Sep 20 20:57:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 20:57:21 +0100 (BST)
Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:59918 "EHLO
	grey.subnet.at") by linux-mips.org with ESMTP id <S8225395AbVITT5G>;
	Tue, 20 Sep 2005 20:57:06 +0100
Received: from ip6-localhost ([193.170.141.4]) by grey.subnet.at ; Tue, 20 Sep 2005 21:56:55 +0200
From:	Bruno Randolf <bruno.randolf@4g-systems.biz>
To:	ppopov@embeddedalley.com
Subject: Re: stale board ports, again
Date:	Tue, 20 Sep 2005 21:52:30 +0200
User-Agent: KMail/1.8.1
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
References: <1127245542.4948.269.camel@localhost.localdomain>
In-Reply-To: <1127245542.4948.269.camel@localhost.localdomain>
Organization: 4G Systems
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1667452.WjQsCKnhBj";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200509202152.34589.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9002
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips
Content-Length: 1050
Lines: 42

--nextPart1667452.WjQsCKnhBj
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi pete!

just starting to use the mtx-1 boards with 2.6: i just submitted a flash ma=
p=20
for it to the mtd project, in order to be merged back to linux-mips later.=
=20
works well.=20

currently 2.4 is still the default for mtx-1 based products, but we will be=
=20
switching to 2.6 soon... 4g systems will maintain it, or at least send=20
patches to you.

bruno

On Tuesday 20 September 2005 21:45, Pete Popov wrote:
> Is there anyone using the mtx-1, csb250, or xxs1500 in 2.6? If so, how
> badly broken are they and does anyone want to maintain them or is it
> time to nuke them?
>
> Thanks,
>
> Pete

--nextPart1667452.WjQsCKnhBj
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDMGiCfg2jtUL97G4RAjCaAJ0cf1avnmhBirsKjCQZh7W0L/FhjQCbBgW/
WOVO5bYbuuE+pw259kGhXjI=
=dR0B
-----END PGP SIGNATURE-----

--nextPart1667452.WjQsCKnhBj--

From ppopov@embeddedalley.com Tue Sep 20 21:12:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 21:12:33 +0100 (BST)
Received: from smtp101.biz.mail.mud.yahoo.com ([IPv6:::ffff:68.142.200.236]:65410
	"HELO smtp101.biz.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225377AbVITUMR>; Tue, 20 Sep 2005 21:12:17 +0100
Received: (qmail 71366 invoked from network); 20 Sep 2005 20:12:10 -0000
Received: from unknown (HELO ?192.168.1.105?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp101.biz.mail.mud.yahoo.com with SMTP; 20 Sep 2005 20:12:09 -0000
Subject: Re: stale board ports, again
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Michael Kelly <mike@cogcomp.com>
Cc:	Bruno Randolf <bruno.randolf@4g-systems.biz>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <6.2.3.4.2.20050920160654.046fe240@mail.cogcomp.com>
References: <1127245542.4948.269.camel@localhost.localdomain>
	 <200509202152.34589.bruno.randolf@4g-systems.biz>
	 <6.2.3.4.2.20050920160654.046fe240@mail.cogcomp.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 20 Sep 2005 13:12:15 -0700
Message-Id: <1127247135.4948.296.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9003
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1233
Lines: 48

On Tue, 2005-09-20 at 16:07 -0400, Michael Kelly wrote:
> CSB250 is obsoleted by us and we have not sold one in over a year.

Finally, I get to nuke something :)

Thanks,

Pete

> We have replaced it with the CSB655 Au1550, so keep that one if you
> see it!
> 
> Michael
> 
> At 03:52 PM 9/20/2005, Bruno Randolf wrote:
> >hi pete!
> >
> >just starting to use the mtx-1 boards with 2.6: i just submitted a flash map
> >for it to the mtd project, in order to be merged back to linux-mips later.
> >works well.
> >
> >currently 2.4 is still the default for mtx-1 based products, but we will be
> >switching to 2.6 soon... 4g systems will maintain it, or at least send
> >patches to you.
> >
> >bruno
> >
> >On Tuesday 20 September 2005 21:45, Pete Popov wrote:
> > > Is there anyone using the mtx-1, csb250, or xxs1500 in 2.6? If so, how
> > > badly broken are they and does anyone want to maintain them or is it
> > > time to nuke them?
> > >
> > > Thanks,
> > >
> > > Pete
> >
> 
> Michael J. Kelly
> VP Engineering
> Cogent Computer Systems, Inc.
> ***NEW ADDRESS AND PHONE/FAX***
> 10 Industrial Dr., Unit B
> Smithfield, RI 02917
> tel:401-223-3441 fax:401-223-3442
> www.cogcomp.com
> alternate email: mkelly6505@hotmail.com
> 


From ths@networkno.de Tue Sep 20 21:27:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 21:28:08 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:39081 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8225377AbVITU1p>;
	Tue, 20 Sep 2005 21:27:45 +0100
Received: from port-195-158-179-11.dynamic.qsc.de ([195.158.179.11] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1EHoiI-000872-00; Tue, 20 Sep 2005 22:27:38 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1EHoiH-0003Lj-DL; Tue, 20 Sep 2005 22:27:37 +0200
Date:	Tue, 20 Sep 2005 22:27:37 +0200
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: stale board ports, again
Message-ID: <20050920202737.GK3386@hattusa.textio>
References: <1127245542.4948.269.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1127245542.4948.269.camel@localhost.localdomain>
User-Agent: Mutt/1.5.10i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9004
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 254
Lines: 10

Pete Popov wrote:
> 
> Is there anyone using the mtx-1, csb250, or xxs1500 in 2.6? If so, how
> badly broken are they and does anyone want to maintain them or is it
> time to nuke them?

I hope to support 2.6 xxs1500 in Debian (stable has 2.4).


Thiemo

From jan.pedersen@glaze.dk Tue Sep 20 22:02:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 22:02:26 +0100 (BST)
Received: from mail.glaze.se ([IPv6:::ffff:212.209.188.162]:36102 "HELO
	rocket.glaze.se") by linux-mips.org with SMTP id <S8225411AbVITVCH>;
	Tue, 20 Sep 2005 22:02:07 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP id 8AE6537646C
	for <linux-mips@linux-mips.org>; Tue, 20 Sep 2005 23:02:04 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	<linux-mips@linux-mips.org>
Subject: kernel panic in cfi
Date:	Tue, 20 Sep 2005 23:02:05 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcW+Jo3MWUJuk0tiTkq8LQW1898n2g==
Message-Id: <20050920210204.8AE6537646C@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9005
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 744
Lines: 15

For any of you who are using flash with the cfi driver, this may be of your
interrest:

When using the cfi (common flash interface) driver, every word written to
the flash chips is followed by a operation complete poll. This poll is
intended to have a timeout of 1 ms. However this timeout is calculated by
HZ/1000, which happends to be 0 because HZ < 1000. The result of this is
that there will be just one poll for operation complete. If this single poll
fails, the kernel panics. I have not had the time to investigate this panic
further. Instead, I have made a workaround that increases this timeout to HZ
(1 second). 1 second is far more than needed, but is preferred over a panic.

The patch is available at http://www.jp-embedded.com.



From jan.pedersen@glaze.dk Tue Sep 20 22:12:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 22:13:02 +0100 (BST)
Received: from mail.glaze.se ([IPv6:::ffff:212.209.188.162]:36358 "HELO
	rocket.glaze.se") by linux-mips.org with SMTP id <S8225411AbVITVMr>;
	Tue, 20 Sep 2005 22:12:47 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP id 730CF376471
	for <linux-mips@linux-mips.org>; Tue, 20 Sep 2005 23:12:45 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	<linux-mips@linux-mips.org>
Subject: support for NS DP83847
Date:	Tue, 20 Sep 2005 23:12:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcW+KAwQudJ86A6eQhO01u2hZf0YtQ==
Message-Id: <20050920211245.730CF376471@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9006
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 370
Lines: 7

A patch which adds support for the National semiconducor DP83847 PHY in the
au1000 driver is available at http://www.jp-embedded.com. It is well tested,
feel free to use it. There is also a patch available which adds supports for
the mips based boards available at the same site. If there are iterest of
adding theese to the linux-mips kernel cvs, feel free to do so.



From ilya@total-knowledge.com Tue Sep 20 22:18:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 22:18:55 +0100 (BST)
Received: from users.sonicwall.com ([IPv6:::ffff:67.115.118.5]:786 "EHLO
	us0exb04.us.sonicwall.com") by linux-mips.org with ESMTP
	id <S8225411AbVITVSh>; Tue, 20 Sep 2005 22:18:37 +0100
Received: from us0exb02.us.sonicwall.com ([10.50.128.202]) by us0exb04.us.sonicwall.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 20 Sep 2005 14:18:33 -0700
Received: from [10.0.15.99] ([10.0.15.99]) by us0exb02.us.sonicwall.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 20 Sep 2005 14:18:33 -0700
Message-ID: <43307CA9.1070506@total-knowledge.com>
Date:	Tue, 20 Sep 2005 14:18:33 -0700
From:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Organization: Total Knowledge
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Jan Pedersen <jan.pedersen@glaze.dk>
CC:	linux-mips@linux-mips.org
Subject: Re: support for NS DP83847
References: <20050920211245.730CF376471@rocket.glaze.se>
In-Reply-To: <20050920211245.730CF376471@rocket.glaze.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Sep 2005 21:18:33.0273 (UTC) FILETIME=[DB098290:01C5BE28]
Return-Path: <ilya@total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9007
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@total-knowledge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 662
Lines: 22

If you are interested in any patches being accepted into LMO CVS tree,
you should email patches in question, not URLs. Noone will bother looking
up your stuff on the web.

Jan Pedersen wrote:

>A patch which adds support for the National semiconducor DP83847 PHY in the
>au1000 driver is available at http://www.jp-embedded.com. It is well tested,
>feel free to use it. There is also a patch available which adds supports for
>the mips based boards available at the same site. If there are iterest of
>adding theese to the linux-mips kernel cvs, feel free to do so.
>
>
>
>  
>

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


From jan.pedersen@glaze.dk Tue Sep 20 22:27:05 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 22:27:25 +0100 (BST)
Received: from mail.glaze.se ([IPv6:::ffff:212.209.188.162]:37382 "HELO
	rocket.glaze.se") by linux-mips.org with SMTP id <S8225411AbVITV1F>;
	Tue, 20 Sep 2005 22:27:05 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP
	id 0709137646C; Tue, 20 Sep 2005 23:27:03 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	"'Ilya A. Volynets-Evenbakh'" <ilya@total-knowledge.com>,
	"'Jan Pedersen'" <jan.pedersen@glaze.dk>
Cc:	<linux-mips@linux-mips.org>
Subject: RE: support for NS DP83847
Date:	Tue, 20 Sep 2005 23:27:04 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002B_01C5BE3A.CF97F470"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <43307CA9.1070506@total-knowledge.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcW+KP87K12XIreMQ16849iS5uM48AAAFnRw
Message-Id: <20050920212703.0709137646C@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9008
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 9328
Lines: 164

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C5BE3A.CF97F470
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sorry, patches now included.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Ilya A. Volynets-Evenbakh
> Sent: 20. september 2005 23:19
> To: Jan Pedersen
> Cc: linux-mips@linux-mips.org
> Subject: Re: support for NS DP83847
> 
> If you are interested in any patches being accepted into LMO CVS tree,
> you should email patches in question, not URLs. Noone will bother looking
> up your stuff on the web.
> 
> Jan Pedersen wrote:
> 
> >A patch which adds support for the National semiconducor DP83847 PHY in
> the
> >au1000 driver is available at http://www.jp-embedded.com. It is well
> tested,
> >feel free to use it. There is also a patch available which adds supports
> for
> >the mips based boards available at the same site. If there are iterest of
> >adding theese to the linux-mips kernel cvs, feel free to do so.
> >
> >
> >
> >
> >
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


------=_NextPart_000_002B_01C5BE3A.CF97F470
Content-Type: application/octet-stream;
	name="q5-jp-2.4.31-0.9.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="q5-jp-2.4.31-0.9.tar.gz"

H4sIAAAAAAAAA+xb63PiRhK/r1Dl/6HPm8pi85J4+JlNrRAyqAKISGK9riSlCCFsxSCxkrBNsnt/
+3WPBBZY+JFs7j7EKnaNZnp6erp7un89Ep/qxd9mxUqpVqryRa50/K+/4YIad8jV4V81rlqvVe//
wurigOeqfKXOHdQ4Du8PKgdIX/87hHm91q5PG/Yvq5LQ7EpfdQ6eQ7vWttu/xh+s7F+tkf0PK9UK
fFUZXq/0S3fCiV2i6wQAPcGeDu3RyB7Bj3UI5rOZ54c7WWEeXnn+iuh9gq5kedOdbNub2jAzL20i
uArD2Um5vEFU3sl+sP3A8dyIDfraTnYn27QDy3dmIbbvZIv3105Wv3ICMEejYCkHjD0fwit7U8yh
Z/qjoARsgONak/nIDqLWnazjOqFjTpzfTZqiADPLAdMdgeN/Astzx87l3GddJZLm/22N//31YP9v
NpRmZmhd/aU5Ht//Va5Wq6zvf56vVTj4Ogt8vR69Rs54DMWeOfdh4rjzu9jyJc+/LJu+dVWeOrOg
3DWv7bEzsddoUvppBz+HT6bCcfUixxf5Y+COT/BTOShxywuKXJ3jsvl8/qn5Yj7HRR4RxOFJ5fik
Vlvjg3Ai+/49FCs1vnAAefqDyeb9+yzYLi49C1l4k82/SQ0p2J7NO+ORPQZR6Z3JLaMr9zXjx3o2
35EbWiaTfwf3IiU44B7CT8mDn7P5TAZd/J7KnONm4MoYD6eeG9+VvGxeGzSasvo4z21sUBxFaArN
ppo5eQfc3RHHs+Vn89Ea87QQeAPCnL9DpeSEbrMsTKwre7rYA/vGnMQRlFQBD9fbbBC77PMcZX19
GGyNsXM3n5WsbZbcOuApV9o68K/61lOMl85WI39LdTae4wuHkI/+kK9l4cZzRmAYlI0oBQ0dL4jY
GpiIghx172Xhj2zxjTMGtIDj2qPc0gyaIhrCgEe5YQ8+f97aX8d+tHUKB2bIfmM7ixUB4wGZuRs4
l0iA+TSEYOKFp8lG68r0Yea41BiE/txiizJG9g3s43+nz3SWKP8WA+SGGMFxt1lkk+4p19ikT/GI
w5d4xBZ+R8VKFTjupIqfSqojVFnQqS7dYGTPjKHnTeCtlkA08VaE2DxsL75NM9w3ibZq5Sl27cXI
9y5tt5rGsX3RVJWW1Ku+kGnsIVtkrD+QMZ/OLi3avt0Iss+UrLsQzSEmpo8ftW3qW3Y9j2GtBdoi
CO1pAF39Y5FP44gd/DPZiWSDEEStUXmgOJFMoBtx3wY/lrUOD1nWOjwq8BXmQnhFWzeaKh7SU3qi
0pZU4iYrsNhG1xeNH6SLBhGMHcpt8BPsfrOu9114B7uLXfjllLA2Jpd0VnHM+Yh6XTxBU3+M5oHo
W+juRc+j6JAiepSnNsXfook18R+n4RgNmeOwckzmOKwexBuaXetS9NekKBIG2ELGP4+svkGWTyG7
t1oap54kGorWV6WLp6gkodWRHiWSe8pa//MC/QY2egpNbiF/KuxvGZbhjw8wZ1cwGgOP0Z/Dz0ui
/za2STRwcFI7OKlwqUmAK3CIBQrH5DH5gSYZmi70moLaNATNUAcdCRC1YRK1Cagphi6oLUmnNoKQ
1GbfUTQpesPfAlQ9QYioHRuKCyKMmqLgYgR2iGDFowJ3as4iyrgohm9yutJHnLlXVucTOyhNcS1/
zoTJubZiu8fGvNCYa2O/skXXeS9zexXNWmNm5R81K4sE+fI+bkz2DxqqLJ1BV2mSaZuSJqpyX5eV
HnVm0jIfRFOvGESnLScpBy0rkuisY4YJ3jengF/Hvm1D4I3DW8Qop7Dw5mCZLiBecRCgOcN5aAMg
9jTdURmz0tRDqy+wIeI2d0e2D+xsJbR9zHzeOLpr9QbQsl3bxyIB+vPhxLGg41i2G9hgogDUElzh
WoYLoo+4nZEsWiwLnHnInZ2wnALYDlL5cBMdBEGFJqJ5lkwLgMLlzJAW4EfcPHY2tIeSL2Bihvej
SwlttGUNQFPO9HNBlQDwrq8qH+Sm1MTo9euvgkZtb98CbjxsEHoXANJHjIiaBooKcrffkaVmxAs5
qEJPlyWtgKRyT+wMmnKvVYDGQIeeoqOsclfWibOuFHBqaTk+MRSUs4hbV1LFNrYJDbkj6xdMgDNZ
79HMZzi1AH1B1WVx0BFU6A/UvqJJQGtoyprYEeSu1CyRFBG3noJyf8BUiYttC50OAJtfGOht5AUN
iYJ1RxYa6HmMOy0UWamSqBeQS/wtYoZLQwWhaJ0CaH1JlOmL9FHCxQjqRYEUg1Ffk34cIBF2QlPo
Ci1cW25dKUvR9HvFMM2gBcSBKnVJXOUMJR40NF3WB7oELUVpoklwBk1SP8iipJ1CR9Hu1YZhsoDz
6UKBUSErVBoSsVUONJnpT+7pkqoO2Obag7ZyjqpBmQUc3GSKVmK1kRpQT4p6QYKQfpgxCnDelrAd
HaAHtFZdFUhPmq7Kop6kw2l1RY1Xer986EmtjowYTpSIRCFe57Im7aEFZY0IkDFNfi7gzAOmBrIX
CrhaKXPdpecWmHVBPgOh+UGmZcQj0C00OXYhbNIGYjs2R2IXXOCmD668+WQEV+aNjZvfsp0b3Jwm
WN5ssdpryU29uacnnnsZcbvFrYr092HmlECX64UFuPUdCiehx/ht2+7ocK5Vip3t4LAOXTMIQLjB
TS6a06HvjC7xa1cArsJXjwuoFYEtpkwlbJywvmMRPC7ASlffP+xiuS+tI8CKZZQ+xKN8mto1naY2
4/yBN7HTh1h87eCIP/JDK7V/ZE/MBetJ9pnBtGzN5hsjqBURaOi4Yy+lC1N6Suu1vWBpJKWLsp1v
XwYpXb5NE6V0zC5DKqhSeuLTqpQhQ0KpqzUmT5AGWsNQ2qKMGbIMkstKNXKaW8+/Nn3yldWpPpFB
03Pttm2OGD2KjtkLI77l+f6c5QFyRuQxRU95E0H25UwRUmeTGWfyR+y/P/1aE0nVRcJUyNeF+PAC
bWd4M/R0thAjvj1N8mAHOBFS8G1M2BCf2eT/iBB5eR/amF8boqaWtAtNl7oGiyhK5yft3FA1/Rfw
hgHzbiI35wbbRZMcd7cEFwXg7gSJvvHiHk7+ZTVvfHCUACqJ2TPzaoUOY4zx3LVO4/tgERiICT5Z
oT8psDtrch341L+pjz5ZJ4Pq1ogx4C0M5wE9HAl9bzKxMQ9nEuIW6ByRtISEhtiVuiRqZnM91fF4
vKIUz1pGQ8C4uEk5Xmd21npIsdJNgrB73hW0H4ym9GGTfoOMJjVU6YMhip2HYlZMlLN+sDYGsbku
dpvpa7K42hpxu6nqF/2Hy4plPlqXpiGoS8pg4Vq5vTX/yqADxfsDrRVZYOJZ1zBybhxCZ7dYzYLc
xMwehAiDCCi5HqMzrRBpwkWJeVdCEvzm416a5NAhjT7mR1XU1c4efAYUsgrffQf1PUx3a50pDsI2
TGa5R97Btw+2SWZ9c+OAOFdgQiEJFmCzXtzWGezI/fteNO7OtEhZlaM9+BY3QIXb2wPy6szMd9zw
OrfLhjruZayPUqn0s7vLNJlYajrDzxFD2lirRhr4JRK5Pw+ZvBFjx8Xd2yRobMdibjAUIwlrKB9t
d4xO0IhUnqbz1TCLhv0HxyXEsFbyr1yBhFq6w5c/V5SxXPjcaiwifmEZFg36yvVXzHSjnq4+UXgd
ca+F12vh9Vp4vRZer4XX31Z4ba2uthRK24suqjam9uYoVlaMRn4wM620kmNLMRRPhvHVTa8KrxHc
25MnRKRz0ZCUPDVM/5KgMXuuub+/bLopLG9s92Z2uqoaGCZfPc2lfvpmWNMRTmFH0PyeOmLKyC7t
EDnlohb85ppTmygZw9y+YdwOx5N5cLUHKyZxpxkBybg/if4NAxVlGCgUBmk6VM/tEqbYXVUQVLyG
sRQoACIOerplhIuZneTjYy5EaXfXE+XukgupanPFOWok1RVi9vuR0uIbUlqBPUCOVn9jW8uKZe1B
8j76ReD8bhto0NNkL+0JiDuZKjIrY8E7iG22aruJ2m5WbTQ/tsW2Y6qK9UeUawpl/cvXERHbLUu1
DOEVY2paV5dYrBK3riC2jZaqDPqG0BHbUvfiNElGWl1SRQ9vEoKveQnDfImV46ikj+zGXRHSZaA5
QRxD5LgF6K0Pwkd0MSgJ9gSDygZN4ExnEzY89Ca5BLcC9AYdzEHcChzjnjSQwPMXBhXhnkulVTwC
c4+i6AZWfoYqRNVf7Dvc0lkwxWPUNrSLbkPp5O7d+rkvBmwCxOhRxrORbUz+UmwbD/va6HbJdgPf
1k/4o8fw7QH/im9f8e0rvn3Ft6/49m/Dt7bvu+ngcivyfXgIn4ScBh3OpSNmbzTf8giB4I75FFrd
7CGksXmwvxQdgxmdl7/06UfoTO27dDEm5jC1w8e476XXAtsffAyd0JulPZR47NlHWuMjzzcilPv4
U4xsHm/u7u7oHUxEbzMjhPWGn35B2EQo6g+I3mMyWn1ZMSocT0FPFw38z+go50YHtxcBKPhSSKGu
vIi6+iLqWoK6LbfaK/JU6vqLeB8kqM8wKxhSsyVtpT58jPeX02UREWvY9dmbrwyW/m5749y65vfK
qc1GyGqiVGDX9Kz51HZDFiPKYvzbDtxx9mQWg69akatChT+pVU74h6/uPsB0z+AYwbmjkzp3wuOY
2kM4V+GPo5f46O/qLT56batYrRSHZoBxtGEi6ocVfot9NwZj1hV6OXbj16EdEk65dr1b9mbbjWOy
SNmTKujUCMzodzBZyObTf8iTzW++xx5PEZ3Or//QJsHibcDkhUjY+5/bECyLb2Ee4HiSJX7hjx5u
YswmRIjBmza1P2V6BHPoRefuQWJ8AbEqbtD4p0O3t7elzZ8PfY8xPAvJVyubkhhEtgmyy2cV2EaP
cAgVwyOLQ7L1RdHzyCUzVDwJPrJD05kE/8DfBL1e/5zrvwAAAP//AwCQiJTNADwAAA==

------=_NextPart_000_002B_01C5BE3A.CF97F470
Content-Type: application/octet-stream;
	name="dp83847-jp-2.4.31-1.0.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="dp83847-jp-2.4.31-1.0.tar.gz"

H4sIAAAAAAAAA+wZa2/iSHK+gpT/UJvRjmB4tY15ZrMXwuMGhZAIO7uz0kmWg5vgDdjIbs9mtJv7
7VfdfmAwsGQ2p/mSEsG4u7reXVXdMVfNalNplH5fleSyUq5KJalM3r0ugEIapAbvFFKtKdX1E2Ig
IJGqJMv1ulyT8L3eqBN4V3tlOd4gDeYu/1d2jpZXBpvOv4GHREhdUfb5X5KVRn3T/5JcJzj/Bv9/
MK3ZDEpjw3dhYdn+U+jvsuM+VEzX+kJdr2JTVjF89CLRKZuXpxuYe7GypVLpeJoZmZBaiWCgtYC0
2vip1cskAiiRGiHZQqFwHO+QWrMkyxhMbVlpI/skNQWpXVxAqdaqFetQ4I9WAy4uspBxKfNdG8hZ
Fp6zkC1YNgPb08WG0F3qUZbzmOtPcZQy3aRfrCmFj/gsAkddzb/qhmm6+WwB/sS/ADypDkvL0qeO
zVxnUQRmLanjs7NsAXEqFY6zcnH9Y+4UmQk2/7FP82cxhcRqOIelaTmIZZg5wThiWoTr4VDv3oy1
yc0ouZij/+FajB7AL27w+CuYGmsjfdJX+9oGNbowvuakxNDMcSEX6oTioSfOIhXhZ7QllErhaz5h
FXgN3SKwZpDLJSl92NYAzs+B5FMLI7hHno9puju0fY5/caaHeaa1Df181Z+M9f5kAqc/enD76TcQ
To+t9gO6vwhogdLPtrGkOxQOA7Uk7RJsHcUFProVxpZtfUMU8yA2DWac7QpZTjKM2FiIykdQmbMC
w2dOyaYPDrMMZjk2fKzEJDjBlzg9WHVkQAviH+C/sVM6d9rNUWQQSBHIE88XL99IMb8B7gRuhsRu
GvQ+o/4pO6HrDROTGbM8uqToAubgNqrw9YZtwidjMasM/MUCTH+1oE+Qm/GXqbEy7q2FxSzq5QOz
BnCMWTvjTu+XhHIohnOPsdi5U/twb7EUvb/Oxbrxr53fdO1zqFT4JvRKjqQGzjiD9asCtsPAc1Yr
x2XURGZwrJ2F4IF3t+14+XVleB4skCDGN8WGxbIf/vVSy4xVHXdkV5skE82GCWIE/fJWV7VJX+t+
Olb89eLdOkyoxwyX7dk2x2uRzpVJFYIkpWpiTyQDlL+/OOJTehxOQKgg872jUlARfMw7H7HuP4Y/
vRWl5mZ99cP6GqWnMGEF5MPOAJPVF4MhC8NfJSXlOfwHZHtUrt7SAKjrOm4bxnejEU/WmzU7goOZ
GqVBR+b2yJoPSgB/T8oc6ZoOASSH6BtOUrWOdqfmd6btQI02/EiUJ1FxIsoJNaIiF2bTiKQ+Go6v
dhlN+Ip3ATuK6UvkDvaJqql7qv2WTDG6rt72+z1dIruEi4UUUYRyDAf67c1EQ/TLDlbsNKsIhCOs
mc7z1THrnlMjdOFROCDTQaV6d7ejPqZZjLRDeh3QTwg6+Lxfw7/V9G8ppHXe0P3bxdb+sdiHKKTF
fk5stvXsHiWigCdpDrE+O+b2yHs3vhrf/Do+pquD99bMpDPANDwY/lu/Ht6q+uWNimTu1KzIoh7z
71/S7qF2/FxUlwk/FzUkqSjJ4lyEZ6H31MbjIj8ThbT4MmflrdM6fzlPGGij4Symh0XLu2M8yEo4
8cyTHmyxu58u9ZpMpJgdZOKhgFFiIGQhlGq0hFKNejE86/15OlKH0CSy3IiarUvDoxrvx0+LvPuT
6viYNRVsBj8sPEsXuJxxkTwXBYWhzegCRp+1VkPqQM83FqAKn69pVPHRaFKZ03hiiGdsULjidrXh
Sm22WrXrPYLIMj4kpcYFefQ45jImUkAiY4Nh42hB71aYMFiIDSyehEUjW5tW+dINV3H+ByMI6aoY
QIKQJFcVQajeaCIhEVgxkSAyuJGbDZkbudUgxWZg5EzmmX/zL4zZzI7jTxs6vvQEY4enPGCuYXtT
Kk72eLD0bXPHWSiTqKkBUhsD86A233DVMT/qumH+oquOOb+cUEpELklNIM12tb59OfGSq4751lVH
VWpXGzuvOpp17hf8loPgf4+Gsmy6Lufdzjjq48kTriIxTmYTRxGblTw1BU62gC0rVi1MTg+WxwKn
uTBWIQhE3rQmecUVTdCQSGp20FW7k4CDpKRmJ/1gks/W0pS7ajxb38WXd91itpWaxUKuCc44a6Rm
u71gKZ+958UhOszE6uCJyduvreiWktk/J+X3oUb9yxr1p5/2YycagxhbzqdEFOIfkHHrMBOTam6R
Cg2xj1IwjQ+9P+5cjvpJFWppHUL0yRAL9PC6v6HxDpVD9EFnNNpGb+VFAggjVoTssCfpN3dDfXST
yZCnQZeQDOqxcP4IpHdmgLOwNLxHrkl67fVNrz/iS0l1IJYuHRNzve0v76nLl3zv29t/Drvv/yf9
Tu+6/1o8Dt//A1Qbytb/fxoNuQavxf4NDoBmsQUtc2gDjMU1AzYwURPh+eJ25iTb8dnccUO031cX
GC4UN4FpUrM8dZYn2U/OksLKeKAcYc7Yql2pbCFVTrK/YHVADgEZDLST7Em2R72pa6045xNeSCM4
yWpzywNsS71IDlFY2JyuBeUtz9SxTWwPcSrR+2BbKzCDUnmSxVpJXaydENTRMuf8vW3/Bm/wveF/
AAAA//8DAK3Vs74AIAAA

------=_NextPart_000_002B_01C5BE3A.CF97F470--



From jan.pedersen@glaze.dk Tue Sep 20 22:28:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Sep 2005 22:28:36 +0100 (BST)
Received: from mail.glaze.se ([IPv6:::ffff:212.209.188.162]:37894 "HELO
	rocket.glaze.se") by linux-mips.org with SMTP id <S8225421AbVITV2R>;
	Tue, 20 Sep 2005 22:28:17 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP
	id 9B33D37646C; Tue, 20 Sep 2005 23:28:15 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	"'Jan Pedersen'" <jan.pedersen@glaze.dk>,
	<linux-mips@linux-mips.org>
Subject: RE: kernel panic in cfi
Date:	Tue, 20 Sep 2005 23:28:16 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002E_01C5BE3A.FAF55590"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20050920210204.8AE6537646C@rocket.glaze.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcW+Jo3MWUJuk0tiTkq8LQW1898n2gAA2ILA
Message-Id: <20050920212815.9B33D37646C@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9009
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 3144
Lines: 65

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C5BE3A.FAF55590
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Patch attached.

> For any of you who are using flash with the cfi driver, this may be of
> your
> interrest:
> 
> When using the cfi (common flash interface) driver, every word written to
> the flash chips is followed by a operation complete poll. This poll is
> intended to have a timeout of 1 ms. However this timeout is calculated by
> HZ/1000, which happends to be 0 because HZ < 1000. The result of this is
> that there will be just one poll for operation complete. If this single
> poll
> fails, the kernel panics. I have not had the time to investigate this
> panic
> further. Instead, I have made a workaround that increases this timeout to
> HZ
> (1 second). 1 second is far more than needed, but is preferred over a
> panic.
> 
> The patch is available at http://www.jp-embedded.com.


------=_NextPart_000_002E_01C5BE3A.FAF55590
Content-Type: application/octet-stream;
	name="cfi_workaround-jp-2.4.31-1.0.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="cfi_workaround-jp-2.4.31-1.0.tar.gz"

H4sIAAAAAAAAA+xX+2sbRxDOrzq4/2EaaJFiPe5OOjl14uK0SWoT7NIQGigFs7rb0619r+7uWXFD
//d+uytZklPbaZMSCh6w7zXv+WZnlGTidFHLcybrtkoHZ80gGk6G43AQDoMHn4loEuwGMT2YBON4
Ml5f6YoCCoNxGAVRGEUB4WF3PKEH8edy4J5upOSW+o9ev3j2/PjFJ9sIg2A6mdxY/ygej9f1D3dR
/3A3mtKnB3dPd9IboQs+NLRHBDDQOZcVL6hhlUhojQzKakkOGr73rNV5LZdCZ80BUMPLGU9Tng6T
uvS9w7rkUDHnhiHXutkbja4xjXzvFy6VqCunBnjzPd97tWHe9wYb5Htvc15Rq0Q1J51z620Xmsq6
oqxgKidRaS4zlvAepVJccNknjv+XJo6UFlJoDQ26NuK+52SSXDSKhEKARVEveEqzS2JUN1wyDe8I
FpqCa8QDhiG9ycFrbo2MMVghIOj0vZxdcEhqUfK61VRnFFKphnQIrfACRiGx+orbhBVJWzDtTB7+
OkKfBH1a5CLJjbamgW5l3J1xnJAznrBWcTDSUzKsxhdOkqu2sNasfmMiZ9pEKDktBPycIdazVoGn
ckHYWn4Y4JCOlkpMiosVLxOF6tuEO2j4ni0OAjsiG3JVa9yklsWEZzwW1QVXWswRnVPp8JS10jgG
0UppztK+7y2VlCw1ydsAnA1DVInkTHG1nT1YQBq6ISme1FXaG9Lq1vdMKZmkspbGNKuo4hwl6tPM
pb2RPONSIuu1qQpzrg0N+N4K4Lq1ycNbneSEIhTCsFb25QaG6eeYZjWTqJBsq8qAEv5G0wkdH/6B
xGvUsG7gMCuQ4SoT89bYVJKVxEw/WfThOyRdfuEv3GMz40EUD+Lga4CTVXNuist8b6szRUaXdWsx
za1rvNICGpza7jii4+97LigmrXclVwodud1U675aMKENm8EGM5gojZdI9BX+hcvBRttsuk0IpJa+
t3R5BUJ6jjw1EF1CEXgFVJiiXMxzPGeuTPzKommMFSCXrtnSr/vhCokuekUmYYDOdpzbfed7M54z
cYHgoAuOmrIYcytbBZo+05abo671ue0uufIPQkv9vrc04DytMncgLV2XvASqUpv4L320fxTdOv9v
+zi0DfJRNu6a/+NJeG3/m8a4/LeB35OlVGQZDU5YK6kQVftuWeFhLecjN0PVqNTpyPa7BURSporr
UwygaJhsCX2MgDl9/pWlThQEk0EI7O1SMN2LJ3sRULgiGgRxEHg7Ozv/2COjOB4EjwdRRGG0F072
wt0txRMoPjigQRwG/V3acZeDA486AC8OFBwehcJegsl9SULbiYkjgB6NVj9vwJr+PqV9+uH4eTd8
+nTae2JfxetXMV4NOna+4eUZqiJwsu1Qd7kX9J7Q6BFmnLaH9MYcDEtlz+yqXsCit/P3Om4W35Km
Tgd/dZEqzTQi2jdL1qk5srsla/rEUmldv/WzydW3cdAPI9ox18cuWSZbtFZNm9K0Eier3rJe8d3N
iszZq8i61N2w8Q0F74Lg5Uvq0f4+vnz4uoeE3SX61U2iS+vvvQFdo0ZiMzzv0sPl8N2zY1AyobAC
YMHDcoXtC8vcegtbMLNOQrKeY6VTbl1xTKsZldJPr36rHiLwa3H/ieeOeejwQvFtd94bNy0XAGC8
MMM60WgLUjUtoB0rUlpjgMIs13aQKV03bqmw9h0wOh07DszIddU2yA3evQx6fbsNDL5DjqQ2Vbkp
Ha9evD45ffvs9cnRyY/08Mhs6xXmsNsoUn4hEr5en5PELkwAp1tytlOFB+C2vEqn02G+GJ+Rcpco
7/8xhe/pnr4M/QUAAP//AwBkhPzFABQAAA==

------=_NextPart_000_002E_01C5BE3A.FAF55590--



From swamim@sankhya.com Wed Sep 21 11:18:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 11:19:18 +0100 (BST)
Received: from [IPv6:::ffff:210.212.208.205] ([IPv6:::ffff:210.212.208.205]:46224
	"EHLO pdns.sankhya.co.in") by linux-mips.org with ESMTP
	id <S8225261AbVIUKS6>; Wed, 21 Sep 2005 11:18:58 +0100
Received: from sankhya.com (sankhya-external [192.168.1.2])
	by pdns.sankhya.co.in (8.12.11/8.12.10) with ESMTP id j8LAO3ZU013585
	for <linux-mips@linux-mips.org>; Wed, 21 Sep 2005 15:54:04 +0530
Received: from sankhya.com (localhost [127.0.0.1])
	by sankhya.com (8.12.8/8.12.5) with ESMTP id j8LAlx6Z007937
	for <linux-mips@linux-mips.org>; Wed, 21 Sep 2005 16:17:59 +0530
Received: from localhost (swamim@localhost)
	by sankhya.com (8.12.8/8.12.5/Submit) with ESMTP id j8LAlwIn007932
	for <linux-mips@linux-mips.org>; Wed, 21 Sep 2005 16:17:59 +0530
Date:	Wed, 21 Sep 2005 16:17:58 +0530 (IST)
From:	M Ranga Swami Reddy <swamim@sankhya.com>
To:	linux-mips@linux-mips.org
Subject: Suitable GNU Tool chain for latest MIPS kernel building
Message-ID: <Pine.LNX.4.44.0509211613340.25274-100000@linux42.sankhya.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <swamim@sankhya.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9010
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: swamim@sankhya.com
Precedence: bulk
X-list: linux-mips
Content-Length: 207
Lines: 10


Hello,

Can any one suggest me a suitable GNU tools chain info (ie version
info for binutils, gcc, glibc/newlib) for building the last liunx
kernel for MIPS target. Thanks in advance.

Best Regards,
Swami


From phess.linux@streber24.de Wed Sep 21 15:43:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 15:43:47 +0100 (BST)
Received: from mail.gmx.net ([IPv6:::ffff:213.165.64.20]:23754 "HELO
	mail.gmx.net") by linux-mips.org with SMTP id <S8225263AbVIUOnZ>;
	Wed, 21 Sep 2005 15:43:25 +0100
Received: (qmail 5280 invoked by uid 0); 21 Sep 2005 14:43:18 -0000
Received: from 62.2.248.2 by www52.gmx.net with HTTP;
	Wed, 21 Sep 2005 16:43:19 +0200 (MEST)
Date:	Wed, 21 Sep 2005 16:43:19 +0200 (MEST)
From:	phess.linux@streber24.de
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Subject: newbie question
X-Priority: 3 (Normal)
X-Authenticated: #25484589
Message-ID: <21597.1127313799@www52.gmx.net>
X-Mailer: WWW-Mail 1.6 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-Path: <phess.linux@streber24.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9011
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: phess.linux@streber24.de
Precedence: bulk
X-list: linux-mips
Content-Length: 942
Lines: 25

Hi there!

First I have to say that I'm a newbie without any experience with "linux
kernel". So don't blame me ;-)

I downloaded toolchains from MIPS Technologies.
I downloaded the newest version Linux 2.6.14-rc1 via CVS.

I installed the toolchain and tested some examples like "hello world" and
"minicom". They worked fine. I copied the linux kernel into a new folder of
the toolchain example directory. Then I tried to make (with command sde-make
menuconfig and then sde-make SBD=GSIM32L) the linux kernel. But all I get
are the following five lines:

  CHK     include/linux/version.h
  CC      arch/mips/kernel/asm-offsets.s
gcc: cannot specify -o with -c or -S and multiple compilations
sde-make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1
sde-make: *** [prepare0] Error 2

Now I need some help. Thx!

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

From nigel@mips.com Wed Sep 21 15:50:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 15:51:08 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:57097 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225263AbVIUOus>;
	Wed, 21 Sep 2005 15:50:48 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EI5u3-0003pK-00; Wed, 21 Sep 2005 15:48:55 +0100
Received: from highbury.mips.com ([192.168.192.236])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EI5vc-0006nI-00; Wed, 21 Sep 2005 15:50:32 +0100
Message-ID: <43317338.7080803@mips.com>
Date:	Wed, 21 Sep 2005 15:50:32 +0100
From:	Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Debian Thunderbird 1.0.2 (X11/20050817)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	phess.linux@streber24.de
CC:	linux-mips@linux-mips.org
Subject: Re: newbie question
References: <21597.1127313799@www52.gmx.net>
In-Reply-To: <21597.1127313799@www52.gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.9,
	required 4, AWL, BAYES_00)
Return-Path: <nigel@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9012
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 839
Lines: 26



phess.linux@streber24.de wrote:

>Hi there!
>
>First I have to say that I'm a newbie without any experience with "linux
>kernel". So don't blame me ;-)
>
>I downloaded toolchains from MIPS Technologies.
>I downloaded the newest version Linux 2.6.14-rc1 via CVS.
>
>I installed the toolchain and tested some examples like "hello world" and
>"minicom". They worked fine. I copied the linux kernel into a new folder of
>the toolchain example directory. Then I tried to make (with command sde-make
>menuconfig and then sde-make SBD=GSIM32L) the linux kernel. But all I get
>are the following five lines:
>  
>

Don't try to use the bare-iron/embedded MIPS SDE toolchain to build a 
Linux kernel. Instead use the version which is configured as a Linux 
native or cross compiler. See 
http://www.linux-mips.org/wiki/Toolchains#MIPS_SDE

Nigel

From anemo@mba.ocn.ne.jp Wed Sep 21 16:44:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 16:45:18 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:7126 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225417AbVIUPo6>; Wed, 21 Sep 2005 16:44:58 +0100
Received: from localhost (p8015-ipad210funabasi.chiba.ocn.ne.jp [58.88.127.15])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 7F1258522
	for <linux-mips@linux-mips.org>; Thu, 22 Sep 2005 00:44:53 +0900 (JST)
Date:	Thu, 22 Sep 2005 00:43:27 +0900 (JST)
Message-Id: <20050922.004327.74753021.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Subject: sparse for mips
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9013
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 346
Lines: 15

Hi.  I got following error on make C=1

  CHECK   /home/anemo/linux/scripts/mod/empty.c
No such file: 0

It seems sparse can not handle '-G 0' option correctly.  I'm using
this snapshot:

http://www.codemonkey.org.uk/projects/git-snapshots/sparse/sparse-2005-09-21.tar.gz

Is there any trick to run sparse on mips?

Thank you.
---
Atsushi Nemoto

From ralf@linux-mips.org Wed Sep 21 17:10:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 17:10:17 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:47119 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8225472AbVIUQKA>; Wed, 21 Sep 2005 17:10:00 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8LG9rgI015841;
	Wed, 21 Sep 2005 17:09:53 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8LG9nGH015840;
	Wed, 21 Sep 2005 17:09:49 +0100
Date:	Wed, 21 Sep 2005 17:09:49 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: sparse for mips
Message-ID: <20050921160949.GA6150@linux-mips.org>
References: <20050922.004327.74753021.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050922.004327.74753021.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9014
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 368
Lines: 12

On Thu, Sep 22, 2005 at 12:43:27AM +0900, Atsushi Nemoto wrote:

> It seems sparse can not handle '-G 0' option correctly.  I'm using
> this snapshot:
> 
> http://www.codemonkey.org.uk/projects/git-snapshots/sparse/sparse-2005-09-21.tar.gz
> 
> Is there any trick to run sparse on mips?

Sparse used to work fine for MIPS out of the box, so this is a new bug.

  Ralf

From imipak@yahoo.com Wed Sep 21 18:24:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Sep 2005 18:25:02 +0100 (BST)
Received: from web31503.mail.mud.yahoo.com ([IPv6:::ffff:68.142.198.132]:37482
	"HELO web31503.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225552AbVIURYn>; Wed, 21 Sep 2005 18:24:43 +0100
Received: (qmail 82845 invoked by uid 60001); 21 Sep 2005 17:24:36 -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=Qn9JcmBx6YYmK+5v3Iifb4Qf2VXkBZ8xzHO69XDbrsOd+HHCedWWV/FrkxPp98EvSc40QrcKr4u17DC/0wA8MGncFpFPu9/g/8+mlDbTH8AswwtFPRgq1j2ecV3yl5lJk8aCUhlY2yuRMVRoK3qHy4N6pcdf17TdHZhIr3Yqcig=  ;
Message-ID: <20050921172436.82843.qmail@web31503.mail.mud.yahoo.com>
Received: from [208.187.37.98] by web31503.mail.mud.yahoo.com via HTTP; Wed, 21 Sep 2005 10:24:35 PDT
Date:	Wed, 21 Sep 2005 10:24:35 -0700 (PDT)
From:	Jonathan Day <imipak@yahoo.com>
Subject: Building the kernel for a Broadcom SB1
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <imipak@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9015
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: imipak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 779
Lines: 25

Hi,

Things've been interesting here, of late. I've got the
toolchain to compile natively 64-bit code (with
considerable effort and the instructions from Linux
From Scratch) and I have a working Linux 2.6.12-rc2
kernel with the SB1 patches from the linux-mips
mailing lists.

So far, so good. Tried compiling the 2.6.14-rc1
kernel, forward-porting all the changes that hadn't
been merged in. the kernel locks in the initial boot
sequence, after a couple of printf's.

Are there any kernel patches for the Broadcom/SiByte
processors that are specific to the 2.6.13-* or
2.6.14-*, or any options that are definitely producing
Bad Code on these kernels but not earlier?



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

From raghavanvinay@yahoo.com Thu Sep 22 03:03:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 03:04:15 +0100 (BST)
Received: from web32102.mail.mud.yahoo.com ([IPv6:::ffff:68.142.207.116]:36543
	"HELO web32102.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8225617AbVIVCD4>; Thu, 22 Sep 2005 03:03:56 +0100
Received: (qmail 77345 invoked by uid 60001); 22 Sep 2005 02:03:49 -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=HHKINGEIzbfF4trZ81x+QyzmOg7BzpaUrrox1alri9SD02nNWHl6EqhjkAFvj8ir827vcK4DckF5/qmDPEr27AuHT44Iqv+7SgJ91avx7DOx/oBAhOm1CBStuaWxx8eMCq8keT+MyA6HFYcT9iDrqQgP0mpsjgN3ZmOykfDudvM=  ;
Message-ID: <20050922020349.77343.qmail@web32102.mail.mud.yahoo.com>
Received: from [66.236.104.214] by web32102.mail.mud.yahoo.com via HTTP; Wed, 21 Sep 2005 19:03:49 PDT
Date:	Wed, 21 Sep 2005 19:03:49 -0700 (PDT)
From:	Vinay Venkataraghavan <raghavanvinay@yahoo.com>
Subject: Kernel panic problem
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <raghavanvinay@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9016
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: raghavanvinay@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1403
Lines: 77


Hey guys,


I am getting the following error running Linux on a
MIPS platform.

Its basically a kernel panic errror. The error message
is as below.

Any help/pointers would be of great help. 
Thanks
Vinay


Got mcheck at c0043938

Cpu 0

$ 0   : 00000000 1000e801 c0050000 00000000

$ 4   : 00000093 810b1000 8034bec8 b8038030

$ 8   : 00004000 00000000 1000e800 80dea000

$12   : 00ff0000 ff000000 00000025 c1100000

$16   : 81aebee8 00000000 00000001 00000000

$20   : 8034bec8 00000093 00000010 00000010

$24   : 00000001 00000003                  

$28   : 8034a000 8034be40 fffffffc 80144588

Hi    : 00000000

Lo    : 00000000

epc   : c0043938 linux_layer_isr+0xc/0x28 [n2_drv]    
Tainted: P     

ra    : 80144588 handle_IRQ_event+0x78/0xfc

Status: 1020e803    KERNEL EXL IE 

Cause : 00800060

PrId  : 0001800a

 

Index:  0 pgmask=4kb va=c0046000 asid=45

                        [pa=01ee0000 c=3 d=1 v=1 g=1]

                        [pa=01ee1000 c=3 d=1 v=1 g=1]

 

Index:  8 pgmask=4kb va=c004a000 asid=45

                        [pa=01ee4000 c=3 d=1 v=1 g=1]

                        [pa=00000000 c=0 d=0 v=0 g=1]

 

Kernel panic - not syncing: Caught Machine Check
exception - caused by multiple matching entries in the
TLB.
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From maillist@jg555.com Thu Sep 22 06:12:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 06:12:56 +0100 (BST)
Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:57770
	"EHLO jg555.com") by linux-mips.org with ESMTP id <S8224774AbVIVFMf>;
	Thu, 22 Sep 2005 06:12:35 +0100
Received: from [172.16.0.55] ([::ffff:172.16.0.55])
  (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by jg555.com with esmtp; Wed, 21 Sep 2005 22:12:31 -0700
  id 0009871F.43323D3F.00007CDC
Message-ID: <43323D35.9030905@jg555.com>
Date:	Wed, 21 Sep 2005 22:12:21 -0700
From:	Jim Gifford <maillist@jg555.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: MIPS64 NPTL Status
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <maillist@jg555.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9017
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maillist@jg555.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1453
Lines: 34

Looking through the latest glibc snapshot they have removed linuxthreads 
and moved it to ports. I know Daniel has been working on getting NPTL to 
work on MIPS32, which it does. Thank you Daniel. I know from emails I 
read around linux-mips.org he was going to work on MIPS64 NPTL, just 
curious to the status.

For the record the current glibc snapshot will not build at all under 
MIPS64. Here is the error message I have received, still working on 
getting it to build properly

In file included from ../sysdeps/mips/libc-tls.c:20:
../sysdeps/generic/libc-tls.c: In function '__libc_setup_tls':
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL_DECL'
../sysdeps/generic/libc-tls.c:191: error: 'err' undeclared (first use in 
this function)
../sysdeps/generic/libc-tls.c:191: error: (Each undeclared identifier is 
reported only once
../sysdeps/generic/libc-tls.c:191: error: for each function it appears in.)
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL'
../sysdeps/generic/libc-tls.c:191: error: 'set_thread_area' undeclared 
(first use in this function)
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL_ERROR_P'
make[2]: *** [/mnt/lfs-mips64/build/glibc-cross-64bit/csu/libc-tls.o] 
Error 1
make[2]: Leaving directory `/mnt/lfs-mips64/build/glibc-20050919/csu'

-- 
----
Jim Gifford
maillist@jg555.com


From adi@hexapodia.org Thu Sep 22 08:23:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 08:23:29 +0100 (BST)
Received: from straum.hexapodia.org ([IPv6:::ffff:64.81.70.185]:33202 "EHLO
	straum.hexapodia.org") by linux-mips.org with ESMTP
	id <S8224983AbVIVHXH>; Thu, 22 Sep 2005 08:23:07 +0100
Received: by straum.hexapodia.org (Postfix, from userid 22448)
	id 5B724298; Thu, 22 Sep 2005 00:22:59 -0700 (PDT)
Date:	Thu, 22 Sep 2005 00:22:59 -0700
From:	Andy Isaacson <adi@hexapodia.org>
To:	Jonathan Day <imipak@yahoo.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Building the kernel for a Broadcom SB1
Message-ID: <20050922072259.GC6920@hexapodia.org>
References: <20050921172436.82843.qmail@web31503.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE"
Content-Disposition: inline
In-Reply-To: <20050921172436.82843.qmail@web31503.mail.mud.yahoo.com>
User-Agent: Mutt/1.4.2i
X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1  B8 DF 39 B2 AF A3 16 B9
X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt
X-Domestic-Surveillance: money launder bomb tax evasion
Return-Path: <adi@hexapodia.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9018
X-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
Content-Length: 23388
Lines: 1017


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Sep 21, 2005 at 10:24:35AM -0700, Jonathan Day wrote:
> So far, so good. Tried compiling the 2.6.14-rc1
> kernel, forward-porting all the changes that hadn't
> been merged in. the kernel locks in the initial boot
> sequence, after a couple of printf's.

We'd be able to help more if you simply pasted in the console output
rather than being vague.

> Are there any kernel patches for the Broadcom/SiByte
> processors that are specific to the 2.6.13-* or
> 2.6.14-*, or any options that are definitely producing
> Bad Code on these kernels but not earlier?

I'm building and testing CVS HEAD as of Wednesday afternoon with the
attached patch and .config.

-andy

Cleaning up state...
Transferring control to the kernel.
Kernel entry point is at 0x803e1000
Broadcom SiByte BCM1250 B2 @ 600 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
@@@@ This is a BCM1250 B1/B2, but the kernel is conservatively configured for an 'A' stepping. @@@@
Linux version 2.6.14-rc1 (adi@bobble) (gcc version 3.4.1 broadcom_2004e_341 (SpecifixInc)) #1 SMP Wed Sep 21 23:59:40 PDT 2005
CPU revision is: 01040102
FPU revision is: 000f0102
swarm setup: M41T81 RTC detected.
This kernel optimized for board runs with CFE
Determined physical RAM map:
 memory: 000000000fe9be00 @ 0000000000000000 (usable)
 memory: 000000001ffffe00 @ 0000000080000000 (usable)
 memory: 000000000ffffe00 @ 00000000c0000000 (usable)
 memory: 000000001ffffe00 @ 0000000100000000 (usable)
Built 1 zonelists
Kernel command line: root=/dev/nfs ip=any nfsroot=XXX
Primary instruction cache 32kB, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (40 instructions).
Synthesized TLB load handler fastpath (54 instructions).
Synthesized TLB store handler fastpath (49 instructions).
Synthesized TLB modify handler fastpath (48 instructions).
PID hash table entries: 4096 (order: 12, 131072 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 1489260k/1571424k available (2360k kernel code, 81480k reserved, 585k data, 204k init, 0k highmem)
Mount-cache hash table entries: 256
Checking for 'wait' instruction...  unavailable.
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
Detected 1 available secondary CPU(s)
CPU revision is: 03040102
FPU revision is: 000f0102
Primary instruction cache 32kB, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (40 instructions).
Brought up 2 CPUs
NET: Registered protocol family 16
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 9220K size 1024 blocksize
eth0: enabling TCP rcv checksum
eth0: enabling TCP rcv checksum
eth0: SiByte Ethernet at 0x10064000, address: 00:02:4C:FE:0A:96
eth1: enabling TCP rcv checksum
eth1: enabling TCP rcv checksum
eth1: SiByte Ethernet at 0x10065000, address: 00:02:4C:FE:0A:97
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
NET: Registered protocol family 2
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
eth0: Link speed: 100BaseT FDX
eth1: Link speed: 1000BaseT FDX
Sending DHCP requests ., OK


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=sibyte-fixes

Fix problems for SiByte chips:
 - CONFIG_64BIT build fixes
 - remove MIPS_CPU_4KTLB from ->options because sb1 has its own TLB routines

 arch/mips/kernel/cpu-probe.c           |    2 ++
 arch/mips/mm/c-sb1.c                   |    4 ++++
 include/asm-mips/addrspace.h           |    1 +
 include/asm-mips/mach-generic/spaces.h |    7 ++++---
 4 files changed, 11 insertions(+), 3 deletions(-)

Index: lmo-1480/include/asm-mips/addrspace.h
===================================================================
--- lmo-1480.orig/include/asm-mips/addrspace.h	2005-09-15 14:20:58.000000000 -0700
+++ lmo-1480/include/asm-mips/addrspace.h	2005-09-15 14:21:06.000000000 -0700
@@ -131,6 +131,7 @@
     || defined (CONFIG_CPU_R5000)					\
     || defined (CONFIG_CPU_NEVADA)					\
     || defined (CONFIG_CPU_TX49XX)					\
+    || defined (CONFIG_CPU_SB1)						\
     || defined (CONFIG_CPU_MIPS64_R1)
 #define KUSIZE		_LLCONST_(0x0000010000000000)	/* 2^^40 */
 #define KUSIZE_64	_LLCONST_(0x0000010000000000)	/* 2^^40 */
Index: lmo-1480/include/asm-mips/mach-generic/spaces.h
===================================================================
--- lmo-1480.orig/include/asm-mips/mach-generic/spaces.h	2005-09-15 14:20:58.000000000 -0700
+++ lmo-1480/include/asm-mips/mach-generic/spaces.h	2005-09-15 14:21:06.000000000 -0700
@@ -11,6 +11,7 @@
 #define _ASM_MACH_GENERIC_SPACES_H
 
 #include <linux/config.h>
+#include <asm/addrspace.h>
 
 #ifdef CONFIG_32BIT
 
@@ -63,9 +64,9 @@
 #define UNCAC_BASE		0x9000000000000000
 #define MAP_BASE		0xc000000000000000
 
-#define TO_PHYS(x)		(             ((x) & TO_PHYS_MASK))
-#define TO_CAC(x)		(CAC_BASE   | ((x) & TO_PHYS_MASK))
-#define TO_UNCAC(x)		(UNCAC_BASE | ((x) & TO_PHYS_MASK))
+#define TO_PHYS(x)		(             ((unsigned long)(x) & TO_PHYS_MASK))
+#define TO_CAC(x)		(CAC_BASE   | ((unsigned long)(x) & TO_PHYS_MASK))
+#define TO_UNCAC(x)		(UNCAC_BASE | ((unsigned long)(x) & TO_PHYS_MASK))
 
 #endif /* CONFIG_64BIT */
 
Index: lmo-1480/arch/mips/mm/c-sb1.c
===================================================================
--- lmo-1480.orig/arch/mips/mm/c-sb1.c	2005-09-15 14:20:58.000000000 -0700
+++ lmo-1480/arch/mips/mm/c-sb1.c	2005-09-15 14:21:06.000000000 -0700
@@ -503,7 +503,11 @@
 
 	/* Special cache error handler for SB1 */
 	set_uncached_handler (0x100, &except_vec2_sb1, 0x80);
+#ifdef CONFIG_32BIT
 	memcpy((void *)KSEG1ADDR(&handle_vec2_sb1), &handle_vec2_sb1, 0x80);
+#elif defined(CONFIG_64BIT)
+	memcpy((void *)TO_UNCAC(&handle_vec2_sb1), &handle_vec2_sb1, 0x80);
+#endif
 
 	probe_cache_sizes();
 
Index: lmo-1480/arch/mips/kernel/cpu-probe.c
===================================================================
--- lmo-1480.orig/arch/mips/kernel/cpu-probe.c	2005-09-15 14:20:58.000000000 -0700
+++ lmo-1480/arch/mips/kernel/cpu-probe.c	2005-09-15 14:21:06.000000000 -0700
@@ -612,6 +612,8 @@
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SB1:
 		c->cputype = CPU_SB1;
+		/* SB1 uses custom TLB code */
+		c->options &= ~MIPS_CPU_4KTLB;
 #ifdef CONFIG_SB1_PASS_1_WORKAROUNDS
 		/* FPU in pass1 is known to have issues. */
 		c->options &= ~(MIPS_CPU_FPU | MIPS_CPU_32FPR);

--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14-rc1
# Wed Sep 21 23:54:37 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_CPUSETS=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Machine selection
#
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_PNX8550_V2PCI is not set
# CONFIG_PNX8550_JBS is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_QEMU is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
CONFIG_SIBYTE_SWARM=y
# CONFIG_SIBYTE_SENTOSA is not set
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
# CONFIG_TOSHIBA_RBTX4938 is not set
CONFIG_SIBYTE_SB1250=y
CONFIG_SIBYTE_SB1xxx_SOC=y
# CONFIG_CPU_SB1_PASS_1 is not set
CONFIG_CPU_SB1_PASS_2_1250=y
# CONFIG_CPU_SB1_PASS_2_2 is not set
# CONFIG_CPU_SB1_PASS_4 is not set
# CONFIG_CPU_SB1_PASS_2_112x is not set
# CONFIG_CPU_SB1_PASS_3 is not set
CONFIG_CPU_SB1_PASS_2=y
CONFIG_SIBYTE_HAS_LDT=y
# CONFIG_SIMULATION is not set
CONFIG_SIBYTE_CFE=y
# CONFIG_SIBYTE_CFE_CONSOLE is not set
# CONFIG_SIBYTE_BUS_WATCHER is not set
# CONFIG_SIBYTE_SB1250_PROF is not set
# CONFIG_SIBYTE_TBPROF is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_COHERENT=y
CONFIG_CPU_BIG_ENDIAN=y
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_SWAP_IO_SPACE=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
# CONFIG_CPU_MIPS32_R1 is not set
# CONFIG_CPU_MIPS32_R2 is not set
# CONFIG_CPU_MIPS64_R1 is not set
# CONFIG_CPU_MIPS64_R2 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
CONFIG_CPU_SB1=y
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y

#
# Kernel type
#
# CONFIG_32BIT is not set
CONFIG_64BIT=y
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
# CONFIG_SIBYTE_DMA_PAGEOPS is not set
# CONFIG_MIPS_MT is not set
CONFIG_SB1_PASS_2_WORKAROUNDS=y
CONFIG_SB1_PASS_2_1_WORKAROUNDS=y
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
CONFIG_CPU_HAS_SYNC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_CPU_SUPPORTS_HIGHMEM=y
CONFIG_SYS_SUPPORTS_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_BUILD_ELF64=y
CONFIG_MIPS32_COMPAT=y
CONFIG_COMPAT=y
CONFIG_MIPS32_O32=y
# CONFIG_MIPS32_N32 is not set
CONFIG_BINFMT_ELF32=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
CONFIG_INET_TUNNEL=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=9220
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_ATA_OVER_ETH=m

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=y
CONFIG_BLK_DEV_IDEFLOPPY=y
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_BLK_DEV_IDE_SWARM is not set
# CONFIG_IDE_ARM is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
CONFIG_PHYLIB=m
CONFIG_PHYCONTROL=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
CONFIG_NET_SB1250_MAC=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
# CONFIG_IPW_DEBUG is not set
CONFIG_IPW2200=m

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_LIBPS2 is not set
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_STALDRV is not set
CONFIG_SIBYTE_SB1250_DUART=y
CONFIG_SIBYTE_SB1250_DUART_CONSOLE=y

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""
# CONFIG_SB1XXX_CORELIS is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m

--Kj7319i9nmIyA2yE--

From matej.kupljen@ultra.si Thu Sep 22 10:28:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 10:28:57 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:25306 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8225008AbVIVJ2k>; Thu, 22 Sep 2005 10:28:40 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 9446FC07C
	for <linux-mips@linux-mips.org>; Thu, 22 Sep 2005 11:28:32 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id 1CAFC1BC08D
	for <linux-mips@linux-mips.org>; Thu, 22 Sep 2005 11:28:35 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 62FE61A18AE
	for <linux-mips@linux-mips.org>; Thu, 22 Sep 2005 11:28:34 +0200 (CEST)
Subject: Re: CVS Update@linux-mips.org: linux
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	linux-mips@linux-mips.org
In-Reply-To: <20050921213950Z8225559-3678+10018@linux-mips.org>
References: <20050921213950Z8225559-3678+10018@linux-mips.org>
Content-Type: text/plain
Date:	Thu, 22 Sep 2005 11:28:23 +0200
Message-Id: <1127381303.13577.0.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9019
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 219
Lines: 14

Hi

> Modified files:
> 	arch/mips/au1000/common: platform.c 
> 
> Log message:
> 	smc91x platform support; requires patch to smc91x.h which was sent
> 	upstream.

Can I see the patch, or where was it send?

BR,
Matej


From kbaidarov@dev.rtsoft.ru Thu Sep 22 12:34:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 12:34:40 +0100 (BST)
Received: from [IPv6:::ffff:85.21.88.2] ([IPv6:::ffff:85.21.88.2]:60882 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225233AbVIVLeY>; Thu, 22 Sep 2005 12:34:24 +0100
Received: (qmail 14576 invoked from network); 22 Sep 2005 11:34:23 -0000
Received: from localhost.localdomain.dev.rtsoft.ru (HELO ?192.168.1.158?) (192.168.1.158)
  by mail.dev.rtsoft.ru with SMTP; 22 Sep 2005 11:34:23 -0000
Message-ID: <43329632.8070400@dev.rtsoft.ru>
Date:	Thu, 22 Sep 2005 15:32:02 +0400
From:	kbaidarov <kbaidarov@dev.rtsoft.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Fedora/1.7.10-1.3.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: [patch] db1550: useless memset() call
Content-Type: multipart/mixed;
 boundary="------------010503060804050403090207"
Return-Path: <kbaidarov@dev.rtsoft.ru>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9020
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kbaidarov@dev.rtsoft.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 1578
Lines: 42

This is a multi-part message in MIME format.
--------------010503060804050403090207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've try kernel without memset() on the board - is ok, board boot.
All drivers works fine. Than I grep the kernel sources:

[root@windmill linux]# grep -nri "memset(irq_desc" arch/
arch/mips/au1000/common/irq.c:449:      memset(irq_desc, 0, sizeof(irq_desc));
arch/mips/ite-boards/generic/irq.c:184:        memset(irq_desc, 0, sizeof(irq_desc));
[root@windmill linux]#

Only 2 matches! Does we needs memset() at all?
And if some one try to initialize irq_desc from start_kernel() before arch_init_irq() call, then following arch_init_irq() call discard all that initialization.


--------------010503060804050403090207
Content-Type: text/x-patch;
 name="lm_db1550_irq_desc.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="lm_db1550_irq_desc.patch"

Description:
Removes useless memset() call.
Signed-off-by: Konstantin Baydarov<kbaidarov@dev.rtsoft.ru>

Index: linux_up/linux/arch/mips/au1000/common/irq.c
===================================================================
--- linux_up.orig/linux/arch/mips/au1000/common/irq.c
+++ linux_up/linux/arch/mips/au1000/common/irq.c
@@ -446,7 +446,6 @@ void __init arch_init_irq(void)
 	extern int au1xxx_ic0_nr_irqs;
 
 	cp0_status = read_c0_status();
-	memset(irq_desc, 0, sizeof(irq_desc));
 	set_except_vector(0, au1000_IRQ);
 
 	/* Initialize interrupt controllers to a safe state.

--------------010503060804050403090207--

From anemo@mba.ocn.ne.jp Thu Sep 22 16:11:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 16:11:53 +0100 (BST)
Received: from mba.ocn.ne.jp ([210.190.142.172]:61410 "HELO smtp.mba.ocn.ne.jp")
	by ftp.linux-mips.org with SMTP id S8133354AbVIVPLf (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 22 Sep 2005 16:11:35 +0100
Received: from localhost (p5050-ipad25funabasi.chiba.ocn.ne.jp [220.104.83.50])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 29E4883C5; Fri, 23 Sep 2005 00:11:32 +0900 (JST)
Date:	Fri, 23 Sep 2005 00:10:06 +0900 (JST)
Message-Id: <20050923.001006.25910318.anemo@mba.ocn.ne.jp>
To:	ralf@linux-mips.org
Cc:	linux-mips@linux-mips.org
Subject: Re: sparse for mips
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050921160949.GA6150@linux-mips.org>
References: <20050922.004327.74753021.anemo@mba.ocn.ne.jp>
	<20050921160949.GA6150@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: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9021
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 267
Lines: 10

>>>>> On Wed, 21 Sep 2005 17:09:49 +0100, Ralf Baechle <ralf@linux-mips.org> said:

ralf> Sparse used to work fine for MIPS out of the box, so this is a
ralf> new bug.

Hmm... Thanks.  Could you tell me when you got the working sparse last
time ?

---
Atsushi Nemoto

From imipak@yahoo.com Thu Sep 22 18:22:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 18:23:20 +0100 (BST)
Received: from web31513.mail.mud.yahoo.com ([68.142.198.142]:22101 "HELO
	web31513.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP
	id S8133358AbVIVRW5 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 22 Sep 2005 18:22:57 +0100
Received: (qmail 6758 invoked by uid 60001); 22 Sep 2005 17:22:50 -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=3oZa1rsmUxwe57iSfuAFRUcLZBYKOaW70f9flSQKnvUFV5ugkrLCBBeVPfmf7hksW8e3MFS8wVtiFQyYUC6UB4Z1s+VADe7GO2GJNHR01n+SkOeu4XcQnKlok+rq0X4yUk4aKzE2J4q2upUvLmxWQNd9n3ic+56LHCjXy8Yb0p8=  ;
Message-ID: <20050922172250.6756.qmail@web31513.mail.mud.yahoo.com>
Received: from [208.187.37.98] by web31513.mail.mud.yahoo.com via HTTP; Thu, 22 Sep 2005 10:22:50 PDT
Date:	Thu, 22 Sep 2005 10:22:50 -0700 (PDT)
From:	Jonathan Day <imipak@yahoo.com>
Subject: Re: Building the kernel for a Broadcom SB1
To:	Andy Isaacson <adi@hexapodia.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050922072259.GC6920@hexapodia.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2022303379-1127409770=:5559"
Content-Transfer-Encoding: 8bit
Return-Path: <imipak@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9023
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: imipak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 27572
Lines: 510

--0-2022303379-1127409770=:5559
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Id: 
Content-Disposition: inline

Oops, my bad! Ok, well here is the entire log for the
boot sequence, including non-kernel stuff. I've also
attached the kernel configuration I'm using.

Incidently, I'm now not so sure it's a bug in the
kernel that's the factor - I've done some experiments
and discovered that there may be a bug in the ZBus.
Code that runs quickly will hard-crash the processor,
but adding anything that just inserts wait states or
otherwise slows down activity will cause the code to
run just fine.

To see if this could be related to the kernel issues,
I recompiled kernel sources I -know- absolutely works
with the board. Where it had debugging code enabled
for the Infiniband and a few other places, for the
working build, I disabled the debugs. everything else
was kept exactly the same. The whole system locked
absolutely solid.

I'll try the suggested patches & config - with and
without the debugs enabled - to see what happens. I'm
also going to scour around for diagnostic tools to see
if I can get a clearer picture of what is happening
and why.

Jonathan


Initializing Arena.
Initializing PCI. [normal]
PCI bus 0 slot 1/0: Warning: SipReady already set
PCI bus 0 slot 1/0: HT init: InitDone not set
PCI bus 0 slot 1/0:   Link Cmd = 0x20010008, Link Ctrl
= 0x00000000
Initializing Devices.
SENTOSA board revision 2
Config switch: 2
CPU: BCM1250 rev 0x11
L2 Cache Status: Wafer ID:   0x92CEE019  [Lot 9395,
Wafer 23]
Manuf Test: Bin A [2CPU_FI_FD_F2 (OK)]
SysCfg: 0000000024C20800 [PLL_DIV: 16, IOB0_DIV:
CPUCLK/4, IOB1_DIV:
CPUCLK/3]
CPU type 0x1040102: 800MHz
Total memory: 0x10000000 bytes (256MB)
                                                      
                                                      
               
Total memory used by CFE:  0x8FE99CE0 - 0x90000000
(1467168)
Initialized Data:          0x8FE99CE0 - 0x8FEA3B60
(40576)
BSS Area:                  0x8FEA3B60 - 0x8FEA41A0
(1600)
Local Heap:                0x8FEA41A0 - 0x8FFA41A0
(1048576)
Stack Area:                0x8FFA41A0 - 0x8FFA61A0
(8192)
Text (code) segment:       0x8FFA61A0 - 0x8FFFFFBC
(368156)
Boot area (physical):      0x0FE58000 - 0x0FE98000
Relocation Factor:         I:F03A61A0 - D:0FE98CE0
                                                      
                                                      
               
eth0: Link speed: 100BaseT FDX
Device eth0:  hwaddr 00-02-4C-FD-0D-3C, ipaddr
10.1.1.53, mask
255.255.0.0
        gateway 10.1.1.1, nameserver 10.1.1.3, domain
xyronsemi.com
Loader:elf Filesys:tftp Dev:eth0
File:10.1.1.52:vmlinux.32
Options:(null)
Loading: 0xffffffff80100000/2903912
0xffffffff803c4f68/305896 Entry at
0xffffffff80396000
Closing network.
Starting program at 0xffffffff80396000
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250E (Sentosa)

--- Andy Isaacson <adi@hexapodia.org> wrote:

> On Wed, Sep 21, 2005 at 10:24:35AM -0700, Jonathan
> Day wrote:
> > So far, so good. Tried compiling the 2.6.14-rc1
> > kernel, forward-porting all the changes that
> hadn't
> > been merged in. the kernel locks in the initial
> boot
> > sequence, after a couple of printf's.
> 
> We'd be able to help more if you simply pasted in
> the console output
> rather than being vague.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
--0-2022303379-1127409770=:5559
Content-Type: application/octet-stream; name=config
Content-Transfer-Encoding: base64
Content-Description: 3341867309-config
Content-Disposition: attachment; filename=config

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24n
dCBlZGl0CiMgTGludXgga2VybmVsIHZlcnNpb246IDIuNi4xMi1yYzIKIyBX
ZWQgU2VwIDIxIDE3OjI1OjM2IDIwMDUKIwpDT05GSUdfTUlQUz15CgojCiMg
Q29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zCiMKQ09ORklHX0VYUEVSSU1F
TlRBTD15CkNPTkZJR19DTEVBTl9DT01QSUxFPXkKQ09ORklHX0xPQ0tfS0VS
TkVMPXkKQ09ORklHX0lOSVRfRU5WX0FSR19MSU1JVD0zMgoKIwojIEdlbmVy
YWwgc2V0dXAKIwpDT05GSUdfTE9DQUxWRVJTSU9OPSItZXhwZXJpbWVudGFs
IgpDT05GSUdfU1dBUD15CkNPTkZJR19TWVNWSVBDPXkKQ09ORklHX1BPU0lY
X01RVUVVRT15CiMgQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1QgaXMgbm90IHNl
dApDT05GSUdfU1lTQ1RMPXkKIyBDT05GSUdfQVVESVQgaXMgbm90IHNldAoj
IENPTkZJR19IT1RQTFVHIGlzIG5vdCBzZXQKIyBDT05GSUdfS09CSkVDVF9V
RVZFTlQgaXMgbm90IHNldAojIENPTkZJR19JS0NPTkZJRyBpcyBub3Qgc2V0
CiMgQ09ORklHX0NQVVNFVFMgaXMgbm90IHNldApDT05GSUdfRU1CRURERUQ9
eQpDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKIyBD
T05GSUdfS0FMTFNZTVNfRVhUUkFfUEFTUyBpcyBub3Qgc2V0CkNPTkZJR19C
QVNFX0ZVTEw9eQpDT05GSUdfRlVURVg9eQpDT05GSUdfRVBPTEw9eQojIENP
TkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBpcyBub3Qgc2V0CkNPTkZJR19T
SE1FTT15CkNPTkZJR19DQ19BTElHTl9GVU5DVElPTlM9MApDT05GSUdfQ0Nf
QUxJR05fTEFCRUxTPTAKQ09ORklHX0NDX0FMSUdOX0xPT1BTPTAKQ09ORklH
X0NDX0FMSUdOX0pVTVBTPTAKIyBDT05GSUdfVElOWV9TSE1FTSBpcyBub3Qg
c2V0CkNPTkZJR19CQVNFX1NNQUxMPTAKCiMKIyBMb2FkYWJsZSBtb2R1bGUg
c3VwcG9ydAojCiMgQ09ORklHX01PRFVMRVMgaXMgbm90IHNldAoKIwojIE1h
Y2hpbmUgc2VsZWN0aW9uCiMKIyBDT05GSUdfTUlQU19NVFgxIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUlQU19CT1NQT1JVUyBpcyBub3Qgc2V0CiMgQ09ORklH
X01JUFNfUEIxMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlQU19QQjExMDAg
aXMgbm90IHNldAojIENPTkZJR19NSVBTX1BCMTUwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX01JUFNfUEIxNTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlQU19Q
QjEyMDAgaXMgbm90IHNldAojIENPTkZJR19NSVBTX0RCMTAwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX01JUFNfREIxMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUlQU19EQjE1MDAgaXMgbm90IHNldAojIENPTkZJR19NSVBTX0RCMTU1MCBp
cyBub3Qgc2V0CiMgQ09ORklHX01JUFNfREIxMjAwIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUlQU19NSVJBR0UgaXMgbm90IHNldAojIENPTkZJR19NSVBTX0NP
QkFMVCBpcyBub3Qgc2V0CiMgQ09ORklHX01BQ0hfREVDU1RBVElPTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX01JUFNfRVY2NDEyMCBpcyBub3Qgc2V0CiMgQ09O
RklHX01JUFNfRVY5NjEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01JUFNfSVZS
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUlQU19JVEU4MTcyIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUFDSF9KQVpaIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFTQVQg
aXMgbm90IHNldAojIENPTkZJR19NSVBTX0FUTEFTIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUlQU19NQUxUQSBpcyBub3Qgc2V0CiMgQ09ORklHX01JUFNfU0VB
RCBpcyBub3Qgc2V0CiMgQ09ORklHX01PTUVOQ09fSkFHVUFSX0FUWCBpcyBu
b3Qgc2V0CiMgQ09ORklHX01PTUVOQ09fT0NFTE9UIGlzIG5vdCBzZXQKIyBD
T05GSUdfTU9NRU5DT19PQ0VMT1RfMyBpcyBub3Qgc2V0CiMgQ09ORklHX01P
TUVOQ09fT0NFTE9UX0MgaXMgbm90IHNldAojIENPTkZJR19NT01FTkNPX09D
RUxPVF9HIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlQU19YWFMxNTAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfRERCNTA3NCBpcyBub3Qgc2V0CiMgQ09ORklHX0RE
QjU0NzYgaXMgbm90IHNldAojIENPTkZJR19EREI1NDc3IGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVDX09TUFJFWSBpcyBub3Qgc2V0CiMgQ09ORklHX01BQ0hf
VlI0MVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1DX1lPU0VNSVRFIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0dJX0lQMjIgaXMgbm90IHNldAojIENPTkZJR19T
R0lfSVAyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NHSV9JUDMyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0lCWVRFX1NXQVJNIGlzIG5vdCBzZXQKQ09ORklHX1NJ
QllURV9TRU5UT1NBPXkKIyBDT05GSUdfU0lCWVRFX1JIT05FIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0lCWVRFX0NBUk1FTCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NJQllURV9QVFNXQVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0lCWVRFX0xJ
VFRMRVNVUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NJQllURV9DUkhJTkUgaXMg
bm90IHNldAojIENPTkZJR19TSUJZVEVfQ1JIT05FIGlzIG5vdCBzZXQKIyBD
T05GSUdfU05JX1JNMjAwX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPU0hJ
QkFfSk1SMzkyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPU0hJQkFfUkJUWDQ5
MjcgaXMgbm90IHNldApDT05GSUdfU0lCWVRFX1NCMTI1MD15CkNPTkZJR19T
SUJZVEVfU0IxeHh4X1NPQz15CiMgQ09ORklHX0NQVV9TQjFfUEFTU18xIGlz
IG5vdCBzZXQKIyBDT05GSUdfQ1BVX1NCMV9QQVNTXzJfMTI1MCBpcyBub3Qg
c2V0CkNPTkZJR19DUFVfU0IxX1BBU1NfMl8yPXkKIyBDT05GSUdfQ1BVX1NC
MV9QQVNTXzQgaXMgbm90IHNldAojIENPTkZJR19DUFVfU0IxX1BBU1NfMl8x
MTJ4IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX1NCMV9QQVNTXzMgaXMgbm90
IHNldApDT05GSUdfU0lCWVRFX0hBU19MRFQ9eQojIENPTkZJR19TSU1VTEFU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX1NJQllURV9DRkU9eQpDT05GSUdfU0lC
WVRFX0NGRV9DT05TT0xFPXkKIyBDT05GSUdfU0lCWVRFX0JVU19XQVRDSEVS
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0lCWVRFX1NCMTI1MF9QUk9GIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0lCWVRFX1RCUFJPRiBpcyBub3Qgc2V0CkNPTkZJ
R19SV1NFTV9HRU5FUklDX1NQSU5MT0NLPXkKQ09ORklHX0dFTkVSSUNfQ0FM
SUJSQVRFX0RFTEFZPXkKQ09ORklHX0hBVkVfREVDX0xPQ0s9eQpDT05GSUdf
RE1BX0NPSEVSRU5UPXkKQ09ORklHX0NQVV9CSUdfRU5ESUFOPXkKIyBDT05G
SUdfQ1BVX0xJVFRMRV9FTkRJQU4gaXMgbm90IHNldApDT05GSUdfU1lTX1NV
UFBPUlRTX0JJR19FTkRJQU49eQpDT05GSUdfU1lTX1NVUFBPUlRTX0xJVFRM
RV9FTkRJQU49eQpDT05GSUdfU1dBUF9JT19TUEFDRT15CkNPTkZJR19CT09U
X0VMRjMyPXkKQ09ORklHX01JUFNfTDFfQ0FDSEVfU0hJRlQ9NQoKIwojIENQ
VSBzZWxlY3Rpb24KIwojIENPTkZJR19DUFVfTUlQUzMyIGlzIG5vdCBzZXQK
IyBDT05GSUdfQ1BVX01JUFM2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9S
MzAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9UWDM5WFggaXMgbm90IHNl
dAojIENPTkZJR19DUFVfVlI0MVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BV
X1I0MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX1I0WDAwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQ1BVX1RYNDlYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQ
VV9SNTAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9SNTQzMiBpcyBub3Qg
c2V0CiMgQ09ORklHX0NQVV9SNjAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQ
VV9ORVZBREEgaXMgbm90IHNldAojIENPTkZJR19DUFVfUjgwMDAgaXMgbm90
IHNldAojIENPTkZJR19DUFVfUjEwMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q1BVX1JNNzAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9STTkwMDAgaXMg
bm90IHNldApDT05GSUdfQ1BVX1NCMT15CkNPTkZJR19TWVNfU1VQUE9SVFNf
MzJCSVRfS0VSTkVMPXkKQ09ORklHX1NZU19TVVBQT1JUU182NEJJVF9LRVJO
RUw9eQpDT05GSUdfQ1BVX1NVUFBPUlRTXzMyQklUX0tFUk5FTD15CkNPTkZJ
R19DUFVfU1VQUE9SVFNfNjRCSVRfS0VSTkVMPXkKCiMKIyBLZXJuZWwgdHlw
ZQojCiMgQ09ORklHX01JUFMzMiBpcyBub3Qgc2V0CkNPTkZJR19NSVBTNjQ9
eQpDT05GSUdfNjRCSVQ9eQojIENPTkZJR19QQUdFX1NJWkVfNEtCIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFHRV9TSVpFXzhLQiBpcyBub3Qgc2V0CiMgQ09O
RklHX1BBR0VfU0laRV8xNktCIGlzIG5vdCBzZXQKQ09ORklHX1BBR0VfU0la
RV82NEtCPXkKIyBDT05GSUdfU0lCWVRFX0RNQV9QQUdFT1BTIGlzIG5vdCBz
ZXQKQ09ORklHX0NQVV9IQVNfUFJFRkVUQ0g9eQpDT05GSUdfU0IxX1BBU1Nf
Ml9XT1JLQVJPVU5EUz15CkNPTkZJR19DUFVfSEFTX0xMU0M9eQpDT05GSUdf
Q1BVX0hBU19MTERTQ0Q9eQpDT05GSUdfQ1BVX0hBU19TWU5DPXkKQ09ORklH
X1NNUD15CkNPTkZJR19OUl9DUFVTPTIKIyBDT05GSUdfUFJFRU1QVCBpcyBu
b3Qgc2V0CgojCiMgQnVzIG9wdGlvbnMgKFBDSSwgUENNQ0lBLCBFSVNBLCBJ
U0EsIFRDKQojCkNPTkZJR19IV19IQVNfUENJPXkKQ09ORklHX1BDST15CiMg
Q09ORklHX1BDSV9MRUdBQ1lfUFJPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BD
SV9OQU1FUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSV9ERUJVRyBpcyBub3Qg
c2V0CkNPTkZJR19NTVU9eQoKIwojIFBDQ0FSRCAoUENNQ0lBL0NhcmRCdXMp
IHN1cHBvcnQKIwojIENPTkZJR19QQ0NBUkQgaXMgbm90IHNldAoKIwojIFBD
SSBIb3RwbHVnIFN1cHBvcnQKIwojIENPTkZJR19IT1RQTFVHX1BDSSBpcyBu
b3Qgc2V0CgojCiMgRXhlY3V0YWJsZSBmaWxlIGZvcm1hdHMKIwpDT05GSUdf
QklORk1UX0VMRj15CiMgQ09ORklHX0JJTkZNVF9NSVNDIGlzIG5vdCBzZXQK
Q09ORklHX0JVSUxEX0VMRjY0PXkKIyBDT05GSUdfTUlQUzMyX0NPTVBBVCBp
cyBub3Qgc2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoKIwojIEdlbmVyaWMg
RHJpdmVyIE9wdGlvbnMKIwpDT05GSUdfU1RBTkRBTE9ORT15CkNPTkZJR19Q
UkVWRU5UX0ZJUk1XQVJFX0JVSUxEPXkKIyBDT05GSUdfRldfTE9BREVSIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfRFJJVkVSIGlzIG5vdCBzZXQKCiMK
IyBNZW1vcnkgVGVjaG5vbG9neSBEZXZpY2VzIChNVEQpCiMKIyBDT05GSUdf
TVREIGlzIG5vdCBzZXQKCiMKIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQKIwoj
IENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKCiMKIyBQbHVnIGFuZCBQbGF5
IHN1cHBvcnQKIwoKIwojIEJsb2NrIGRldmljZXMKIwojIENPTkZJR19CTEtf
REVWX0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qg
c2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DT1dfQ09NTU9O
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9MT09QIGlzIG5vdCBzZXQK
IyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtf
REVWX1NYOCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVUIgaXMgbm90
IHNldAojIENPTkZJR19CTEtfREVWX1JBTSBpcyBub3Qgc2V0CkNPTkZJR19C
TEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfSU5JVFJBTUZTX1NPVVJDRT0i
IgojIENPTkZJR19DRFJPTV9QS1RDRFZEIGlzIG5vdCBzZXQKCiMKIyBJTyBT
Y2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1ND
SEVEX0FTPXkKQ09ORklHX0lPU0NIRURfREVBRExJTkU9eQpDT05GSUdfSU9T
Q0hFRF9DRlE9eQojIENPTkZJR19BVEFfT1ZFUl9FVEggaXMgbm90IHNldAoK
IwojIEFUQS9BVEFQSS9NRk0vUkxMIHN1cHBvcnQKIwojIENPTkZJR19JREUg
aXMgbm90IHNldAoKIwojIFNDU0kgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdf
U0NTST15CiMgQ09ORklHX1NDU0lfUFJPQ19GUyBpcyBub3Qgc2V0CgojCiMg
U0NTSSBzdXBwb3J0IHR5cGUgKGRpc2ssIHRhcGUsIENELVJPTSkKIwojIENP
TkZJR19CTEtfREVWX1NEIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9T
VCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0
CiMgQ09ORklHX0JMS19ERVZfU1IgaXMgbm90IHNldApDT05GSUdfQ0hSX0RF
Vl9TRz15CgojCiMgU29tZSBTQ1NJIGRldmljZXMgKGUuZy4gQ0QganVrZWJv
eCkgc3VwcG9ydCBtdWx0aXBsZSBMVU5zCiMKIyBDT05GSUdfU0NTSV9NVUxU
SV9MVU4gaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NPTlNUQU5UUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfTE9HR0lORyBpcyBub3Qgc2V0CgojCiMg
U0NTSSBUcmFuc3BvcnQgQXR0cmlidXRlcwojCiMgQ09ORklHX1NDU0lfU1BJ
X0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9GQ19BVFRSUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NDU0lfSVNDU0lfQVRUUlMgaXMgbm90IHNldAoK
IwojIFNDU0kgbG93LWxldmVsIGRyaXZlcnMKIwojIENPTkZJR19CTEtfREVW
XzNXX1hYWFhfUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfM1dfOVhY
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0FBQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJ
X0FJQzdYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFhfT0xE
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9BSUM3OVhYIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUVHQVJBSURfTkVXR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUVHQVJBSURfTEVHQUNZIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQVRB
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CVVNMT0dJQyBpcyBub3Qgc2V0
CiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19T
Q1NJX0VBVEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01B
SU4gaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0dEVEggaXMgbm90IHNldAoj
IENPTkZJR19TQ1NJX0lQUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5J
VElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNf
RkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5v
dCBzZXQKQ09ORklHX1NDU0lfUUxBMlhYWD15CiMgQ09ORklHX1NDU0lfUUxB
MjFYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjJYWCBpcyBub3Qg
c2V0CiMgQ09ORklHX1NDU0lfUUxBMjMwMCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NDU0lfUUxBMjMyMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBNjMx
MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTV4IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0NTSV9EQzM5MFQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJ
X0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBNdWx0aS1kZXZpY2Ugc3VwcG9ydCAo
UkFJRCBhbmQgTFZNKQojCiMgQ09ORklHX01EIGlzIG5vdCBzZXQKCiMKIyBG
dXNpb24gTVBUIGRldmljZSBzdXBwb3J0CiMKIyBDT05GSUdfRlVTSU9OIGlz
IG5vdCBzZXQKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMK
IyBDT05GSUdfSUVFRTEzOTQgaXMgbm90IHNldAoKIwojIEkyTyBkZXZpY2Ug
c3VwcG9ydAojCiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0CgojCiMgTmV0d29y
a2luZyBzdXBwb3J0CiMKQ09ORklHX05FVD15CgojCiMgTmV0d29ya2luZyBv
cHRpb25zCiMKQ09ORklHX1BBQ0tFVD15CkNPTkZJR19QQUNLRVRfTU1BUD15
CkNPTkZJR19VTklYPXkKIyBDT05GSUdfTkVUX0tFWSBpcyBub3Qgc2V0CkNP
TkZJR19JTkVUPXkKQ09ORklHX0lQX01VTFRJQ0FTVD15CiMgQ09ORklHX0lQ
X0FEVkFOQ0VEX1JPVVRFUiBpcyBub3Qgc2V0CkNPTkZJR19JUF9QTlA9eQpD
T05GSUdfSVBfUE5QX0RIQ1A9eQojIENPTkZJR19JUF9QTlBfQk9PVFAgaXMg
bm90IHNldAojIENPTkZJR19JUF9QTlBfUkFSUCBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0lQR1JFIGlz
IG5vdCBzZXQKIyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQKIyBDT05G
SUdfQVJQRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTl9DT09LSUVTIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5FVF9BSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
RVRfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9JUENPTVAgaXMgbm90
IHNldAojIENPTkZJR19JTkVUX1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lQX1RDUERJQUcgaXMgbm90IHNldAojIENPTkZJR19JUF9UQ1BESUFHX0lQ
VjYgaXMgbm90IHNldAojIENPTkZJR19JUFY2IGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVURklMVEVSIGlzIG5vdCBzZXQKCiMKIyBTQ1RQIENvbmZpZ3VyYXRp
b24gKEVYUEVSSU1FTlRBTCkKIwojIENPTkZJR19JUF9TQ1RQIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFIGlz
IG5vdCBzZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RFQ05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0xMQzIgaXMgbm90IHNl
dAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENPTkZJR19BVEFMSyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBUEIg
aXMgbm90IHNldAojIENPTkZJR19ORVRfRElWRVJUIGlzIG5vdCBzZXQKIyBD
T05GSUdfRUNPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOX1JPVVRFUiBp
cyBub3Qgc2V0CgojCiMgUW9TIGFuZC9vciBmYWlyIHF1ZXVlaW5nCiMKIyBD
T05GSUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19S
T1VURSBpcyBub3Qgc2V0CgojCiMgTmV0d29yayB0ZXN0aW5nCiMKIyBDT05G
SUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFBPTEwgaXMg
bm90IHNldAojIENPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVSIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldAojIENPTkZJR19JUkRB
IGlzIG5vdCBzZXQKIyBDT05GSUdfQlQgaXMgbm90IHNldApDT05GSUdfTkVU
REVWSUNFUz15CiMgQ09ORklHX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdf
Qk9ORElORyBpcyBub3Qgc2V0CiMgQ09ORklHX0VRVUFMSVpFUiBpcyBub3Qg
c2V0CiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0CgojCiMgQVJDbmV0IGRldmlj
ZXMKIwojIENPTkZJR19BUkNORVQgaXMgbm90IHNldAoKIwojIEV0aGVybmV0
ICgxMCBvciAxMDBNYml0KQojCkNPTkZJR19ORVRfRVRIRVJORVQ9eQpDT05G
SUdfTUlJPXkKIyBDT05GSUdfSEFQUFlNRUFMIGlzIG5vdCBzZXQKIyBDT05G
SUdfU1VOR0VNIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09N
IGlzIG5vdCBzZXQKCiMKIyBUdWxpcCBmYW1pbHkgbmV0d29yayBkZXZpY2Ug
c3VwcG9ydAojCiMgQ09ORklHX05FVF9UVUxJUCBpcyBub3Qgc2V0CiMgQ09O
RklHX0hQMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1BDSSBpcyBub3Qg
c2V0CgojCiMgRXRoZXJuZXQgKDEwMDAgTWJpdCkKIwojIENPTkZJR19BQ0VO
SUMgaXMgbm90IHNldAojIENPTkZJR19ETDJLIGlzIG5vdCBzZXQKIyBDT05G
SUdfRTEwMDAgaXMgbm90IHNldAojIENPTkZJR19OUzgzODIwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSEFNQUNISSBpcyBub3Qgc2V0CiMgQ09ORklHX1lFTExP
V0ZJTiBpcyBub3Qgc2V0CiMgQ09ORklHX1I4MTY5IGlzIG5vdCBzZXQKQ09O
RklHX05FVF9TQjEyNTBfTUFDPXkKIyBDT05GSUdfU0s5OExJTiBpcyBub3Qg
c2V0CiMgQ09ORklHX1RJR09OMyBpcyBub3Qgc2V0CgojCiMgRXRoZXJuZXQg
KDEwMDAwIE1iaXQpCiMKIyBDT05GSUdfSVhHQiBpcyBub3Qgc2V0CiMgQ09O
RklHX1MySU8gaXMgbm90IHNldAoKIwojIFRva2VuIFJpbmcgZGV2aWNlcwoj
CiMgQ09ORklHX1RSIGlzIG5vdCBzZXQKCiMKIyBXaXJlbGVzcyBMQU4gKG5v
bi1oYW1yYWRpbykKIwojIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldAoK
IwojIFdhbiBpbnRlcmZhY2VzCiMKIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkRESSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJUFBJIGlzIG5v
dCBzZXQKIyBDT05GSUdfUFBQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xJUCBp
cyBub3Qgc2V0CkNPTkZJR19ORVRfRkM9eQojIENPTkZJR19TSEFQRVIgaXMg
bm90IHNldAojIENPTkZJR19ORVRDT05TT0xFIGlzIG5vdCBzZXQKCiMKIyBJ
U0ROIHN1YnN5c3RlbQojCiMgQ09ORklHX0lTRE4gaXMgbm90IHNldAoKIwoj
IFRlbGVwaG9ueSBTdXBwb3J0CiMKIyBDT05GSUdfUEhPTkUgaXMgbm90IHNl
dAoKIwojIElucHV0IGRldmljZSBzdXBwb3J0CiMKQ09ORklHX0lOUFVUPXkK
CiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKIyBDT05GSUdfSU5QVVRfTU9V
U0VERVYgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9KT1lERVYgaXMgbm90
IHNldAojIENPTkZJR19JTlBVVF9UU0RFViBpcyBub3Qgc2V0CiMgQ09ORklH
X0lOUFVUX0VWREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfRVZCVUcg
aXMgbm90IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJzCiMKIyBDT05G
SUdfSU5QVVRfS0VZQk9BUkQgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9N
T1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5QVVRfVE9VQ0hTQ1JFRU4gaXMgbm90IHNldAoj
IENPTkZJR19JTlBVVF9NSVNDIGlzIG5vdCBzZXQKCiMKIyBIYXJkd2FyZSBJ
L08gcG9ydHMKIwpDT05GSUdfU0VSSU89eQojIENPTkZJR19TRVJJT19JODA0
MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1NFUlBPUlQgaXMgbm90IHNl
dAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldAojIENPTkZJR19T
RVJJT19MSUJQUzIgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19SQVcgaXMg
bm90IHNldAojIENPTkZJR19HQU1FUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19T
T1VORF9HQU1FUE9SVD15CgojCiMgQ2hhcmFjdGVyIGRldmljZXMKIwojIENP
TkZJR19WVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFS
RCBpcyBub3Qgc2V0CkNPTkZJR19TSUJZVEVfU0IxMjUwX0RVQVJUPXkKQ09O
RklHX1NJQllURV9TQjEyNTBfRFVBUlRfQ09OU09MRT15CgojCiMgU2VyaWFs
IGRyaXZlcnMKIwojIENPTkZJR19TRVJJQUxfODI1MCBpcyBub3Qgc2V0Cgoj
CiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9ydAojCiMgQ09ORklHX1NF
UklBTF9KU00gaXMgbm90IHNldApDT05GSUdfVU5JWDk4X1BUWVM9eQojIENP
TkZJR19MRUdBQ1lfUFRZUyBpcyBub3Qgc2V0CgojCiMgSVBNSQojCiMgQ09O
RklHX0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgQ2Fy
ZHMKIwojIENPTkZJR19XQVRDSERPRyBpcyBub3Qgc2V0CkNPTkZJR19SVEM9
eQojIENPTkZJR19EVExLIGlzIG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMg
bm90IHNldAojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CgojCiMgRnRh
cGUsIHRoZSBmbG9wcHkgdGFwZSBkZXZpY2UgZHJpdmVyCiMKIyBDT05GSUdf
RFJNIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFXX0RSSVZFUiBpcyBub3Qgc2V0
CgojCiMgSTJDIHN1cHBvcnQKIwojIENPTkZJR19JMkMgaXMgbm90IHNldAoK
IwojIERhbGxhcydzIDEtd2lyZSBidXMKIwojIENPTkZJR19XMSBpcyBub3Qg
c2V0CgojCiMgTWlzYyBkZXZpY2VzCiMKCiMKIyBNdWx0aW1lZGlhIGRldmlj
ZXMKIwojIENPTkZJR19WSURFT19ERVYgaXMgbm90IHNldAoKIwojIERpZ2l0
YWwgVmlkZW8gQnJvYWRjYXN0aW5nIERldmljZXMKIwojIENPTkZJR19EVkIg
aXMgbm90IHNldAoKIwojIEdyYXBoaWNzIHN1cHBvcnQKIwojIENPTkZJR19G
QiBpcyBub3Qgc2V0CgojCiMgU291bmQKIwojIENPTkZJR19TT1VORCBpcyBu
b3Qgc2V0CgojCiMgVVNCIHN1cHBvcnQKIwpDT05GSUdfVVNCX0FSQ0hfSEFT
X0hDRD15CkNPTkZJR19VU0JfQVJDSF9IQVNfT0hDST15CkNPTkZJR19VU0I9
eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldAoKIwojIE1pc2NlbGxh
bmVvdXMgVVNCIG9wdGlvbnMKIwpDT05GSUdfVVNCX0RFVklDRUZTPXkKIyBD
T05GSUdfVVNCX0JBTkRXSURUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9E
WU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PVEcgaXMg
bm90IHNldAoKIwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNP
TkZJR19VU0JfRUhDSV9IQ0Q9eQpDT05GSUdfVVNCX0VIQ0lfU1BMSVRfSVNP
PXkKIyBDT05GSUdfVVNCX0VIQ0lfUk9PVF9IVUJfVFQgaXMgbm90IHNldApD
T05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfQklHX0VO
RElBTiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfT0hDSV9MSVRUTEVfRU5ESUFO
PXkKIyBDT05GSUdfVVNCX1VIQ0lfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NMODExX0hDRCBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFz
cyBkcml2ZXJzCiMKIyBDT05GSUdfVVNCX0JMVUVUT09USF9UVFkgaXMgbm90
IHNldAojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1BSSU5URVIgaXMgbm90IHNldAoKIwojIE5PVEU6IFVTQl9TVE9SQUdFIGVu
YWJsZXMgU0NTSSwgYW5kICdTQ1NJIGRpc2sgc3VwcG9ydCcgbWF5IGFsc28g
YmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZv
cm1hdGlvbgojCkNPTkZJR19VU0JfU1RPUkFHRT15CkNPTkZJR19VU0JfU1RP
UkFHRV9ERUJVRz15CiMgQ09ORklHX1VTQl9TVE9SQUdFX0RBVEFGQUIgaXMg
bm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9GUkVFQ09NIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfRFBDTSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JB
R0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVN
UFNIT1QgaXMgbm90IHNldAoKIwojIFVTQiBJbnB1dCBEZXZpY2VzCiMKIyBD
T05GSUdfVVNCX0hJRCBpcyBub3Qgc2V0CgojCiMgVVNCIEhJRCBCb290IFBy
b3RvY29sIGRyaXZlcnMKIwojIENPTkZJR19VU0JfS0JEIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX01PVVNFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FJ
UFRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9XQUNPTSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9LQlRBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9Q
T1dFUk1BVEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfTVRPVUNIIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0VHQUxBWCBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9YUEFEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FUSV9SRU1PVEUg
aXMgbm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJ
R19VU0JfTURDODAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01JQ1JPVEVL
IGlzIG5vdCBzZXQKCiMKIyBVU0IgTXVsdGltZWRpYSBkZXZpY2VzCiMKIyBD
T05GSUdfVVNCX0RBQlVTQiBpcyBub3Qgc2V0CgojCiMgVmlkZW80TGludXgg
c3VwcG9ydCBpcyBuZWVkZWQgZm9yIFVTQiBNdWx0aW1lZGlhIGRldmljZSBz
dXBwb3J0CiMKCiMKIyBVU0IgTmV0d29yayBBZGFwdGVycwojCiMgQ09ORklH
X1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0tBV0VUSCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVU
IGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2ZXJzCiMKCiMKIyBVU0Ig
U2VyaWFsIENvbnZlcnRlciBzdXBwb3J0CiMKIyBDT05GSUdfVVNCX1NFUklB
TCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwoj
CiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9F
TUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BVUVSU1dBTEQgaXMgbm90
IHNldAojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0xFR09UT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMg
bm90IHNldAojIENPTkZJR19VU0JfTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX0NZVEhFUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUEhJREdFVEtJ
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QSElER0VUU0VSVk8gaXMgbm90
IHNldAojIENPTkZJR19VU0JfSURNT1VTRSBpcyBub3Qgc2V0CkNPTkZJR19V
U0JfVEVTVD15CgojCiMgVVNCIEFUTS9EU0wgZHJpdmVycwojCgojCiMgVVNC
IEdhZGdldCBTdXBwb3J0CiMKIyBDT05GSUdfVVNCX0dBREdFVCBpcyBub3Qg
c2V0CgojCiMgTU1DL1NEIENhcmQgc3VwcG9ydAojCiMgQ09ORklHX01NQyBp
cyBub3Qgc2V0CgojCiMgSW5maW5pQmFuZCBzdXBwb3J0CiMKQ09ORklHX0lO
RklOSUJBTkQ9eQojIENPTkZJR19JTkZJTklCQU5EX01USENBIGlzIG5vdCBz
ZXQKQ09ORklHX0lORklOSUJBTkRfSVBPSUI9eQojIENPTkZJR19JTkZJTklC
QU5EX0lQT0lCX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMK
IwojIENPTkZJR19FWFQyX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUM19G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX0pCRCBpcyBub3Qgc2V0CiMgQ09ORklH
X1JFSVNFUkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZTIGlzIG5v
dCBzZXQKCiMKIyBYRlMgc3VwcG9ydAojCiMgQ09ORklHX1hGU19GUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdf
Uk9NRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RVU9UQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0ROT1RJRlkgaXMgbm90IHNldAojIENPTkZJR19BVVRPRlNf
RlMgaXMgbm90IHNldAojIENPTkZJR19BVVRPRlM0X0ZTIGlzIG5vdCBzZXQK
CiMKIyBDRC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKIyBDT05GSUdfSVNPOTY2
MF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VERl9GUyBpcyBub3Qgc2V0Cgoj
CiMgRE9TL0ZBVC9OVCBGaWxlc3lzdGVtcwojCiMgQ09ORklHX01TRE9TX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfVkZBVF9GUyBpcyBub3Qgc2V0CiMgQ09O
RklHX05URlNfRlMgaXMgbm90IHNldAoKIwojIFBzZXVkbyBmaWxlc3lzdGVt
cwojCkNPTkZJR19QUk9DX0ZTPXkKQ09ORklHX1BST0NfS0NPUkU9eQojIENP
TkZJR19TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFVkZTX0ZTIGlzIG5v
dCBzZXQKIyBDT05GSUdfREVWUFRTX0ZTX1hBVFRSIGlzIG5vdCBzZXQKQ09O
RklHX1RNUEZTPXkKIyBDT05GSUdfVE1QRlNfWEFUVFIgaXMgbm90IHNldAoj
IENPTkZJR19IVUdFVExCX1BBR0UgaXMgbm90IHNldApDT05GSUdfUkFNRlM9
eQoKIwojIE1pc2NlbGxhbmVvdXMgZmlsZXN5c3RlbXMKIwojIENPTkZJR19B
REZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hGU1BMVVNf
RlMgaXMgbm90IHNldAojIENPTkZJR19CRUZTX0ZTIGlzIG5vdCBzZXQKIyBD
T05GSUdfQkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRUZTX0ZTIGlzIG5v
dCBzZXQKIyBDT05GSUdfQ1JBTUZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhG
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldAoj
IENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19TWVNWX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfVUZTX0ZTIGlzIG5vdCBzZXQKCiMKIyBO
ZXR3b3JrIEZpbGUgU3lzdGVtcwojCkNPTkZJR19ORlNfRlM9eQpDT05GSUdf
TkZTX1YzPXkKIyBDT05GSUdfTkZTX1Y0IGlzIG5vdCBzZXQKIyBDT05GSUdf
TkZTX0RJUkVDVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZTRCBpcyBub3Qg
c2V0CkNPTkZJR19ST09UX05GUz15CkNPTkZJR19MT0NLRD15CkNPTkZJR19M
T0NLRF9WND15CkNPTkZJR19TVU5SUEM9eQojIENPTkZJR19SUENTRUNfR1NT
X0tSQjUgaXMgbm90IHNldAojIENPTkZJR19SUENTRUNfR1NTX1NQS00zIGlz
IG5vdCBzZXQKIyBDT05GSUdfU01CX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q0lGUyBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0NPREFfRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMgaXMg
bm90IHNldAoKIwojIFBhcnRpdGlvbiBUeXBlcwojCiMgQ09ORklHX1BBUlRJ
VElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0CkNPTkZJR19NU0RPU19QQVJUSVRJ
T049eQoKIwojIE5hdGl2ZSBMYW5ndWFnZSBTdXBwb3J0CiMKIyBDT05GSUdf
TkxTIGlzIG5vdCBzZXQKCiMKIyBQcm9maWxpbmcgc3VwcG9ydAojCiMgQ09O
RklHX1BST0ZJTElORyBpcyBub3Qgc2V0CgojCiMgS2VybmVsIGhhY2tpbmcK
IwojIENPTkZJR19QUklOVEtfVElNRSBpcyBub3Qgc2V0CkNPTkZJR19ERUJV
R19LRVJORUw9eQojIENPTkZJR19NQUdJQ19TWVNSUSBpcyBub3Qgc2V0CkNP
TkZJR19MT0dfQlVGX1NISUZUPTE1CiMgQ09ORklHX1NDSEVEU1RBVFMgaXMg
bm90IHNldAojIENPTkZJR19ERUJVR19TTEFCIGlzIG5vdCBzZXQKIyBDT05G
SUdfREVCVUdfU1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19T
UElOTE9DS19TTEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0tPQkpF
Q1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19JTkZPIGlzIG5vdCBzZXQK
IyBDT05GSUdfREVCVUdfRlMgaXMgbm90IHNldAojIENPTkZJR19DUk9TU0NP
TVBJTEUgaXMgbm90IHNldApDT05GSUdfQ01ETElORT0icncgbmZzcm9vdD0x
MC4xLjEuNTI6L25mcyByb290PS9kZXYvbmZzIHNlcmlhbD0xLDExNTIwMG44
IGNvbnNvbGU9dHR5UzEsMTE1MjAwIgojIENPTkZJR19ERUJVR19TVEFDS19V
U0FHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0tHREIgaXMgbm90IHNldAojIENP
TkZJR19TQjFYWFhfQ09SRUxJUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JVTlRJ
TUVfREVCVUcgaXMgbm90IHNldAoKIwojIFNlY3VyaXR5IG9wdGlvbnMKIwoj
IENPTkZJR19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFkgaXMg
bm90IHNldAoKIwojIENyeXB0b2dyYXBoaWMgb3B0aW9ucwojCiMgQ09ORklH
X0NSWVBUTyBpcyBub3Qgc2V0CgojCiMgSGFyZHdhcmUgY3J5cHRvIGRldmlj
ZXMKIwoKIwojIExpYnJhcnkgcm91dGluZXMKIwpDT05GSUdfQ1JDX0NDSVRU
PXkKQ09ORklHX0NSQzMyPXkKQ09ORklHX0xJQkNSQzMyQz15CkNPTkZJR19H
RU5FUklDX0hBUkRJUlFTPXkKQ09ORklHX0dFTkVSSUNfSVJRX1BST0JFPXkK


--0-2022303379-1127409770=:5559--

From drow@nevyn.them.org Thu Sep 22 19:26:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 19:26:32 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:26603 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133361AbVIVS0G (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 22 Sep 2005 19:26:06 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EIVlh-0002rC-9X; Thu, 22 Sep 2005 14:26:01 -0400
Date:	Thu, 22 Sep 2005 14:26:01 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: RFC: Revise n32 ptrace interface
Message-ID: <20050922182601.GA10829@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9024
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 10949
Lines: 350

Currently n32 uses the n64 ptrace interface.  This means that it expects
both of its arguments to be "long long" rather than "long", PTRACE_PEEKTEXT
transfers eight bytes, et cetera.  All of which has combined to cause no end
of trouble for GDB.

Here's an alternative interface that I've just started testing.  n32 uses
the o32 ptrace interface instead, which transfers 32-bit quantities, as we'd
expect from a system with 32-bit longs.  There are only a couple of catches:

1.  We need to get at the 64-bit registers.  I considered a number of
different approaches for this and decided to just implement a 64-bit
PTRACE_GETREGS instead of messing with PTRACE_PEEKUSR.  It's much simpler
this way.  I didn't add one for the DSP registers; that can be handled
separately when someone's working on debug support for them...

2.  While I'm fixing this interface, an n32 program ought to be able to
debug an n64 program.  This copies the clever trick that ppc64 uses,
i.e. passing the 64-bit address via reference.  Less efficient but hugely
simpler.

3.  PTRACE_{GET,SET}SIGINFO.  I didn't even go there.  N32 kernel and glibc
don't even agree about the layout of struct siginfo at the moment.  This
should be investigated, but it's a problem for another day.

Any thoughts on the ABI change?  Just for N32 of course; for o32/n64 this
strictly adds new mechanisms.

NOTE: this patch is just for comments, I don't want it to go in as is. There
ought to be a 32-bit GETREGS while I'm here, and I haven't written GDB
support for the _3264 operations yet, so I haven't tested it much.  I'll be
back to work on this some more in a couple of days.

Index: linux/arch/mips/kernel/ptrace32.c
===================================================================
--- linux.orig/arch/mips/kernel/ptrace32.c	2005-09-21 14:48:02.000000000 -0400
+++ linux/arch/mips/kernel/ptrace32.c	2005-09-22 14:14:06.000000000 -0400
@@ -35,6 +35,12 @@
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
 
+int ptrace_getregs64 (struct task_struct *child, __u64 __user *data);
+int ptrace_setregs64 (struct task_struct *child, __u64 __user *data);
+
+int ptrace_getfpregs (struct task_struct *child, __u32 __user *data);
+int ptrace_setfpregs (struct task_struct *child, __u32 __user *data);
+
 /*
  * Tracing a 32-bit process with a 64-bit strace and vice versa will not
  * work.  I don't know how to fix this.
@@ -99,6 +105,35 @@ asmlinkage int sys32_ptrace(int request,
 		break;
 	}
 
+	/*
+	 * Read 4 bytes of the other process' storage
+	 *  data is a pointer specifying where the user wants the
+	 *	4 bytes copied into
+	 *  addr is a pointer in the user's storage that contains an 8 byte
+	 *	address in the other process of the 4 bytes that is to be read
+	 * (this is run in a 32-bit process looking at a 64-bit process)
+	 * when I and D space are separate, these will need to be fixed.
+	 */
+	case PTRACE_PEEKTEXT_3264:
+	case PTRACE_PEEKDATA_3264: {
+		u32 tmp;
+		int copied;
+		u32 __user * addrOthers;
+
+		ret = -EIO;
+
+		/* Get the addr in the other process that we want to read */
+		if (get_user(addrOthers, (u32 __user * __user *) (unsigned long) addr) != 0)
+			break;
+
+		copied = access_process_vm(child, (u64)addrOthers, &tmp,
+				sizeof(tmp), 0);
+		if (copied != sizeof(tmp))
+			break;
+		ret = put_user(tmp, (u32 __user *) (unsigned long) data);
+		break;
+	}
+
 	/* Read the word at location addr in the USER area. */
 	case PTRACE_PEEKUSR: {
 		struct pt_regs *regs;
@@ -202,6 +237,31 @@ asmlinkage int sys32_ptrace(int request,
 		ret = -EIO;
 		break;
 
+	/*
+	 * Write 4 bytes into the other process' storage
+	 *  data is the 4 bytes that the user wants written
+	 *  addr is a pointer in the user's storage that contains an
+	 *	8 byte address in the other process where the 4 bytes
+	 *	that is to be written
+	 * (this is run in a 32-bit process looking at a 64-bit process)
+	 * when I and D space are separate, these will need to be fixed.
+	 */
+	case PTRACE_POKETEXT_3264:
+	case PTRACE_POKEDATA_3264: {
+		u32 __user * addrOthers;
+
+		/* Get the addr in the other process that we want to write into */
+		ret = -EIO;
+		if (get_user(addrOthers, (u32 __user * __user *) (unsigned long) addr) != 0)
+			break;
+		ret = 0;
+		if (access_process_vm(child, (u64)addrOthers, &data,
+					sizeof(data), 1) == sizeof(data))
+			break;
+		ret = -EIO;
+		break;
+	}
+
 	case PTRACE_POKEUSR: {
 		struct pt_regs *regs;
 		ret = 0;
@@ -276,6 +336,22 @@ asmlinkage int sys32_ptrace(int request,
 		break;
 		}
 
+	case PTRACE_GETFPREGS:
+		ret = ptrace_getfpregs (child, (__u32 __user *) (__u64) data);
+		break;
+
+	case PTRACE_SETFPREGS:
+		ret = ptrace_setfpregs (child, (__u32 __user *) (__u64) data);
+		break;
+
+	case PTRACE_GETREGS64:
+		ret = ptrace_getregs64 (child, (__u64 __user *) (__u64) data);
+		break;
+
+	case PTRACE_SETREGS64:
+		ret = ptrace_setregs64 (child, (__u64 __user *) (__u64) data);
+		break;
+
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
 		ret = -EIO;
@@ -320,6 +396,11 @@ asmlinkage int sys32_ptrace(int request,
 			       (unsigned int __user *) (unsigned long) data);
 		break;
 
+	case PTRACE_GET_THREAD_AREA_3264:
+		ret = put_user(child->thread_info->tp_value,
+				(unsigned long __user *) (unsigned long) data);
+		break;
+
 	default:
 		ret = ptrace_request(child, request, addr, data);
 		break;
Index: linux/include/asm-mips/ptrace.h
===================================================================
--- linux.orig/include/asm-mips/ptrace.h	2005-09-21 14:48:02.000000000 -0400
+++ linux/include/asm-mips/ptrace.h	2005-09-22 13:03:20.000000000 -0400
@@ -50,8 +50,8 @@ struct pt_regs {
 /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
 /* #define PTRACE_GETREGS		12 */
 /* #define PTRACE_SETREGS		13 */
-/* #define PTRACE_GETFPREGS		14 */
-/* #define PTRACE_SETFPREGS		15 */
+#define PTRACE_GETFPREGS		14
+#define PTRACE_SETFPREGS		15
 /* #define PTRACE_GETFPXREGS		18 */
 /* #define PTRACE_SETFPXREGS		19 */
 
@@ -60,6 +60,17 @@ struct pt_regs {
 #define PTRACE_GET_THREAD_AREA	25
 #define PTRACE_SET_THREAD_AREA	26
 
+/* Calls to trace a 64bit program from a 32bit program.  */
+#define PTRACE_PEEKTEXT_3264	0xc0
+#define PTRACE_PEEKDATA_3264	0xc1
+#define PTRACE_POKETEXT_3264	0xc2
+#define PTRACE_POKEDATA_3264	0xc3
+#define PTRACE_GET_THREAD_AREA_3264	0xc4
+
+/* Calls to fetch 64bit registers from an o32 or n32 program.  */
+#define PTRACE_GETREGS64	0xd0
+#define PTRACE_SETREGS64	0xd1
+
 #ifdef __KERNEL__
 
 #include <linux/linkage.h>
Index: linux/arch/mips/kernel/scall64-n32.S
===================================================================
--- linux.orig/arch/mips/kernel/scall64-n32.S	2005-09-21 09:34:45.000000000 -0400
+++ linux/arch/mips/kernel/scall64-n32.S	2005-09-22 14:04:19.000000000 -0400
@@ -216,7 +216,7 @@ EXPORT(sysn32_call_table)
 	PTR	compat_sys_getrusage
 	PTR	sys32_sysinfo
 	PTR	compat_sys_times
-	PTR	sys_ptrace
+	PTR	sys32_ptrace
 	PTR	sys_getuid			/* 6100 */
 	PTR	sys_syslog
 	PTR	sys_getgid
Index: linux/arch/mips/kernel/ptrace.c
===================================================================
--- linux.orig/arch/mips/kernel/ptrace.c	2005-09-22 14:11:07.000000000 -0400
+++ linux/arch/mips/kernel/ptrace.c	2005-09-22 14:11:12.000000000 -0400
@@ -38,6 +38,7 @@
 #include <asm/system.h>
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
+#include <asm/reg.h>
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -49,6 +50,110 @@ void ptrace_disable(struct task_struct *
 	/* Nothing to do.. */
 }
 
+#ifdef CONFIG_64BIT
+int ptrace_getregs64 (struct task_struct *child, __u64 __user *data)
+{
+	struct pt_regs *regs;
+	int i;
+
+	if (!access_ok(VERIFY_WRITE, data, EF_SIZE))
+		return -EIO;
+
+	regs = (struct pt_regs *) ((unsigned long) child->thread_info +
+	       THREAD_SIZE - 32 - sizeof(struct pt_regs));
+
+	for (i = 0; i < 32; i++)
+		__put_user (regs->regs[i], data + EF_R0 + i);
+	__put_user (regs->lo, data + EF_LO);
+	__put_user (regs->hi, data + EF_HI);
+	__put_user (regs->cp0_epc, data + EF_CP0_EPC);
+	__put_user (regs->cp0_badvaddr, data + EF_CP0_BADVADDR);
+	__put_user (regs->cp0_status, data + EF_CP0_STATUS);
+	__put_user (regs->cp0_cause, data + EF_CP0_CAUSE);
+
+	return 0;
+}
+
+int ptrace_setregs64 (struct task_struct *child, __u64 __user *data)
+{
+	struct pt_regs *regs;
+	int i;
+
+	if (!access_ok(VERIFY_READ, data, EF_SIZE))
+		return -EIO;
+
+	regs = (struct pt_regs *) ((unsigned long) child->thread_info +
+	       THREAD_SIZE - 32 - sizeof(struct pt_regs));
+
+	for (i = 0; i < 32; i++)
+		__get_user (regs->regs[i], data + EF_R0 + i);
+	__get_user (regs->lo, data + EF_LO);
+	__get_user (regs->hi, data + EF_HI);
+	__get_user (regs->cp0_epc, data + EF_CP0_EPC);
+
+	/* badvaddr, status, and cause may not be written.  */
+
+	return 0;
+}
+#endif
+
+int ptrace_getfpregs (struct task_struct *child, __u32 __user *data)
+{
+	int i;
+
+	if (!access_ok(VERIFY_WRITE, data, 33 * 8))
+		return -EIO;
+
+	if (tsk_used_math(child)) {
+		fpureg_t *fregs = get_fpu_regs(child);
+		for (i = 0; i < 32; i++)
+			__put_user (fregs[i], i + (__u64 __user *) data);
+	} else {
+		for (i = 0; i < 32; i++)
+			__put_user ((__u64) -1, i + (__u64 __user *) data);
+	}
+
+	if (cpu_has_fpu) {
+		unsigned int flags, tmp;
+
+		__put_user (child->thread.fpu.hard.fcr31, data + 64);
+
+		flags = read_c0_status();
+		__enable_fpu();
+		__asm__ __volatile__("cfc1\t%0,$0" : "=r" (tmp));
+		write_c0_status(flags);
+		__put_user (tmp, data + 65);
+	} else {
+		__put_user (child->thread.fpu.soft.fcr31, data + 64);
+		__put_user ((__u32) 0, data + 65);
+	}
+
+	return 0;
+}
+
+int ptrace_setfpregs (struct task_struct *child, __u32 __user *data)
+{
+	fpureg_t *fregs;
+	int i;
+
+	if (!access_ok(VERIFY_READ, data, 33 * 8))
+		return -EIO;
+
+	fregs = get_fpu_regs(child);
+
+	for (i = 0; i < 32; i++)
+		__get_user (fregs[i], i + (__u64 __user *) data);
+
+	if (cpu_has_fpu)
+		__get_user (child->thread.fpu.hard.fcr31, data + 64);
+	else
+		__get_user (child->thread.fpu.soft.fcr31, data + 64);
+
+	/* FIR may not be written.  */
+
+	return 0;
+}
+
 asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
 {
 	struct task_struct *child;
@@ -300,6 +405,24 @@ asmlinkage int sys_ptrace(long request, 
 		break;
 		}
 
+	case PTRACE_GETFPREGS:
+		ret = ptrace_getfpregs (child, (__u32 __user *) data);
+		break;
+
+	case PTRACE_SETFPREGS:
+		ret = ptrace_setfpregs (child, (__u32 __user *) data);
+		break;
+
+#ifdef CONFIG_64BIT
+	case PTRACE_GETREGS64:
+		ret = ptrace_getregs64 (child, (__u64 __user *) data);
+		break;
+
+	case PTRACE_SETREGS64:
+		ret = ptrace_setregs64 (child, (__u64 __user *) data);
+		break;
+#endif
+
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
 		ret = -EIO;

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From jrc@skylon.demon.co.uk Thu Sep 22 21:38:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 21:38:58 +0100 (BST)
Received: from mta09-winn.ispmail.ntl.com ([81.103.221.49]:52731 "EHLO
	mta09-winn.ispmail.ntl.com") by ftp.linux-mips.org with ESMTP
	id S8133364AbVIVUih (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 22 Sep 2005 21:38:37 +0100
Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35])
          by mta09-winn.ispmail.ntl.com with ESMTP
          id <20050922203827.TVSR9239.mta09-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>;
          Thu, 22 Sep 2005 21:38:27 +0100
Received: from [192.168.129.4] (really [80.4.125.206])
          by aamta12-winn.ispmail.ntl.com with ESMTP
          id <20050922203827.BQNY3160.aamta12-winn.ispmail.ntl.com@[192.168.129.4]>;
          Thu, 22 Sep 2005 21:38:27 +0100
Message-ID: <43331641.1010604@skylon.demon.co.uk>
Date:	Thu, 22 Sep 2005 21:38:25 +0100
From:	John Connett <jrc@skylon.demon.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Linux MIPS List <linux-mips@linux-mips.org>
CC:	Jim Gifford <maillist@jg555.com>
Subject: Re: MIPS64 NPTL Status
References: <43323D35.9030905@jg555.com>
In-Reply-To: <43323D35.9030905@jg555.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jrc@skylon.demon.co.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9025
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jrc@skylon.demon.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 444
Lines: 10

Jim Gifford wrote:
> Looking through the latest glibc snapshot they have removed 
> linuxthreads and moved it to ports. I know Daniel has been working on 
> getting NPTL to work on MIPS32, which it does. Thank you Daniel. I 
> know from emails I read around linux-mips.org he was going to work on 
> MIPS64 NPTL, just curious to the status.
Out of curiosity, is anyone working on using the Multi-Threading ASE to
support NTPL?
-- 
John Connett

From uhler@mips.com Thu Sep 22 21:45:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 21:45:56 +0100 (BST)
Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:7828 "EHLO
	dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133364AbVIVUph
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 22 Sep 2005 21:45:37 +0100
Received: from mercury.mips.com (sbcns-dmz [209.232.97.193])
	by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j8MKitmM020252;
	Thu, 22 Sep 2005 13:44:56 -0700 (PDT)
Received: from laptopuhler4 (laptop-uhler4.mips.com [192.168.20.180])
	by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j8MKiq17025218;
	Thu, 22 Sep 2005 13:44:56 -0700 (PDT)
From:	"Michael Uhler" <uhler@mips.com>
To:	"'John Connett'" <jrc@skylon.demon.co.uk>,
	"'Linux MIPS List'" <linux-mips@linux-mips.org>
Cc:	"'Jim Gifford'" <maillist@jg555.com>
Subject: RE: MIPS64 NPTL Status
Date:	Thu, 22 Sep 2005 13:44:45 -0700
Organization: MIPS Technologies, Inc.
Message-ID: <00cf01c5bfb6$775e0290$b414a8c0@MIPS.COM>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <43331641.1010604@skylon.demon.co.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Importance: Normal
X-Scanned-By: MIMEDefang 2.39
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9026
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 975
Lines: 35

If course.  But we haven't announced schedules yet.



/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler at mips dot com
1225 Charleston Road      Voice:  (650)567-5025
Mountain View, CA 94043

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of John Connett
> Sent: Thursday, September 22, 2005 1:38 PM
> To: Linux MIPS List
> Cc: Jim Gifford
> Subject: Re: MIPS64 NPTL Status
> 
> 
> Jim Gifford wrote:
> > Looking through the latest glibc snapshot they have removed
> > linuxthreads and moved it to ports. I know Daniel has been 
> working on 
> > getting NPTL to work on MIPS32, which it does. Thank you Daniel. I 
> > know from emails I read around linux-mips.org he was going 
> to work on 
> > MIPS64 NPTL, just curious to the status.
> Out of curiosity, is anyone working on using the 
> Multi-Threading ASE to support NTPL?
> -- 
> John Connett
> 
> 


From drow@nevyn.them.org Thu Sep 22 22:30:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 22:30:40 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:15006 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133359AbVIVVaW (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 22 Sep 2005 22:30:22 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EIYe4-0004BP-Hc; Thu, 22 Sep 2005 17:30:20 -0400
Date:	Thu, 22 Sep 2005 17:30:20 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Jim Gifford <maillist@jg555.com>
Cc:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: MIPS64 NPTL Status
Message-ID: <20050922213020.GA15905@nevyn.them.org>
References: <43323D35.9030905@jg555.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43323D35.9030905@jg555.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9027
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1255
Lines: 30

On Wed, Sep 21, 2005 at 10:12:21PM -0700, Jim Gifford wrote:
> Looking through the latest glibc snapshot they have removed linuxthreads 
> and moved it to ports. I know Daniel has been working on getting NPTL to 
> work on MIPS32, which it does. Thank you Daniel. I know from emails I 
> read around linux-mips.org he was going to work on MIPS64 NPTL, just 
> curious to the status.
> 
> For the record the current glibc snapshot will not build at all under 
> MIPS64. Here is the error message I have received, still working on 
> getting it to build properly

Hi Jim,

I've got complete patches to do this.  I thought I'd already submitted
them, but I found out yesterday morning that I hadn't... simply an
accident.  I've posted my complete set of glibc patches here:

http://return.false.org/~drow/mips/glibc-2005-09-22-HEAD-MIPS64-NPTL.tar.gz

As of this morning, they work for me, using GCC HEAD and binutils HEAD.
Rather more work is required for GDB (see my earlier post today and the
last patch in the above tarball).

There are some test failures.  IIRC, at least one of them is a GCC
unwinder bug that I haven't dug out the fix for yet from my archives.
I'm going to try to get all of this merged soon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From drow@nevyn.them.org Thu Sep 22 22:32:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 22:32:29 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:17822 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133359AbVIVVcM (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 22 Sep 2005 22:32:12 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EIYfp-0004CG-AA; Thu, 22 Sep 2005 17:32:09 -0400
Date:	Thu, 22 Sep 2005 17:32:09 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Jonathan Day <imipak@yahoo.com>
Cc:	Andy Isaacson <adi@hexapodia.org>, linux-mips@linux-mips.org
Subject: Re: Building the kernel for a Broadcom SB1
Message-ID: <20050922213209.GB15905@nevyn.them.org>
References: <20050922072259.GC6920@hexapodia.org> <20050922172250.6756.qmail@web31513.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050922172250.6756.qmail@web31513.mail.mud.yahoo.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9028
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 516
Lines: 18

On Thu, Sep 22, 2005 at 10:22:50AM -0700, Jonathan Day wrote:
> Loading: 0xffffffff80100000/2903912
> 0xffffffff803c4f68/305896 Entry at
> 0xffffffff80396000
> Closing network.
> Starting program at 0xffffffff80396000
> Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
> Board type: SiByte BCM91250E (Sentosa)

[*hang* here]

Andy's patches should fix this; I grabbed them from Thiemo's
experimental Debian packages a couple of days ago and they brought my
Sentosa up again.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From maillist@jg555.com Thu Sep 22 23:28:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 23:28:47 +0100 (BST)
Received: from 64-30-195-78.dsl.linkline.com ([64.30.195.78]:55213 "EHLO
	jg555.com") by ftp.linux-mips.org with ESMTP id S8133368AbVIVW2b
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 22 Sep 2005 23:28:31 +0100
Received: from [172.16.0.55] ([::ffff:172.16.0.55])
  (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by jg555.com with esmtp; Thu, 22 Sep 2005 15:28:28 -0700
  id 00098710.4333300C.000062FE
Message-ID: <43333001.3080703@jg555.com>
Date:	Thu, 22 Sep 2005 15:28:17 -0700
From:	Jim Gifford <maillist@jg555.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Daniel Jacobowitz <dan@debian.org>
CC:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: MIPS64 NPTL Status
References: <43323D35.9030905@jg555.com> <20050922213020.GA15905@nevyn.them.org>
In-Reply-To: <20050922213020.GA15905@nevyn.them.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <maillist@jg555.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9029
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maillist@jg555.com
Precedence: bulk
X-list: linux-mips
Content-Length: 999
Lines: 28

Daniel,
    He I still keeping getting this error with the currently 9192005 
snapshot of glibc.

In file included from ../sysdeps/mips/libc-tls.c:20:
../sysdeps/generic/libc-tls.c: In function '__libc_setup_tls':
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL_DECL'
../sysdeps/generic/libc-tls.c:191: error: 'err' undeclared (first use in 
this function)
../sysdeps/generic/libc-tls.c:191: error: (Each undeclared identifier is 
reported only once
../sysdeps/generic/libc-tls.c:191: error: for each function it appears in.)
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL'
../sysdeps/generic/libc-tls.c:191: error: 'set_thread_area' undeclared 
(first use in this function)
../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
function 'INTERNAL_SYSCALL_ERROR_P'
make[2]: *** [/mnt/lfs-mips64/build/glibc-cross-64bit/csu/libc-tls.o] 
Error 1


-- 
----
Jim Gifford
maillist@jg555.com


From drow@nevyn.them.org Thu Sep 22 23:30:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Sep 2005 23:31:10 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:54151 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133368AbVIVWay (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 22 Sep 2005 23:30:54 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EIZae-0004dq-9d; Thu, 22 Sep 2005 18:30:52 -0400
Date:	Thu, 22 Sep 2005 18:30:52 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Jim Gifford <maillist@jg555.com>
Cc:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: MIPS64 NPTL Status
Message-ID: <20050922223052.GA17827@nevyn.them.org>
References: <43323D35.9030905@jg555.com> <20050922213020.GA15905@nevyn.them.org> <43333001.3080703@jg555.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43333001.3080703@jg555.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9030
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 529
Lines: 16

On Thu, Sep 22, 2005 at 03:28:17PM -0700, Jim Gifford wrote:
> Daniel,
>    He I still keeping getting this error with the currently 9192005 
> snapshot of glibc.
> 
> In file included from ../sysdeps/mips/libc-tls.c:20:
> ../sysdeps/generic/libc-tls.c: In function '__libc_setup_tls':
> ../sysdeps/generic/libc-tls.c:191: warning: implicit declaration of 
> function 'INTERNAL_SYSCALL_DECL'

You'll need to provide more context, then, since I don't.  I built
those patches this morning.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From imipak@yahoo.com Fri Sep 23 01:19:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Sep 2005 01:20:14 +0100 (BST)
Received: from web31508.mail.mud.yahoo.com ([68.142.198.137]:47968 "HELO
	web31508.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP
	id S8133376AbVIWAT4 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 23 Sep 2005 01:19:56 +0100
Received: (qmail 63087 invoked by uid 60001); 23 Sep 2005 00:19:49 -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=HyLdzuU9rA3OkyBZsu0ocLemY8ze7/Nv/fK1UgusQ36vacqi/4+ZFrYxlxWV99moOAtpYIrHp6wqoDMQVp02XJXuClyh16XS3nPXccfv6t9r4b21x+ggP0stvIATLdPgCsY6z6t8rxOUFoRJGdD4xBeaaOeeSBcrAGjkyZT1Y/A=  ;
Message-ID: <20050923001949.63085.qmail@web31508.mail.mud.yahoo.com>
Received: from [208.187.37.98] by web31508.mail.mud.yahoo.com via HTTP; Thu, 22 Sep 2005 17:19:49 PDT
Date:	Thu, 22 Sep 2005 17:19:49 -0700 (PDT)
From:	Jonathan Day <imipak@yahoo.com>
Subject: Re: Building the kernel for a Broadcom SB1
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	Andy Isaacson <adi@hexapodia.org>, linux-mips@linux-mips.org
In-Reply-To: <20050922213209.GB15905@nevyn.them.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <imipak@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9031
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: imipak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1156
Lines: 42

I'm trying the patches with various configurations.
Every kernel I've tried building with both the
kobjects and debug info enabled in the kernel hacking
menu will work fine. Any kernel with either (or both)
disabled will lock up on boot.

At this time, I have no clear idea as to why the
debugs are making such a big difference. Particularly
if other people aren't experiencing exactly the same
problem. Any thoughts would be welcome.

--- Daniel Jacobowitz <dan@debian.org> wrote:

> On Thu, Sep 22, 2005 at 10:22:50AM -0700, Jonathan
> Day wrote:
> > Loading: 0xffffffff80100000/2903912
> > 0xffffffff803c4f68/305896 Entry at
> > 0xffffffff80396000
> > Closing network.
> > Starting program at 0xffffffff80396000
> > Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
> > Board type: SiByte BCM91250E (Sentosa)
> 
> [*hang* here]
> 
> Andy's patches should fix this; I grabbed them from
> Thiemo's
> experimental Debian packages a couple of days ago
> and they brought my
> Sentosa up again.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

From p2@debian.org Fri Sep 23 01:29:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Sep 2005 01:30:13 +0100 (BST)
Received: from NAT.office.mind.be ([62.166.230.82]:50836 "EHLO
	NAT.office.mind.be") by ftp.linux-mips.org with ESMTP
	id S8133375AbVIWA34 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 23 Sep 2005 01:29:56 +0100
Received: (qmail 3797 invoked from network); 23 Sep 2005 00:29:54 -0000
Received: from localhost (HELO codecarver) ([127.0.0.1])
          (envelope-sender <p2@debian.org>)
          by localhost (qmail-ldap-1.03) with SMTP
          for <linux-mips@linux-mips.org>; 23 Sep 2005 00:29:54 -0000
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1EIbMP-0006AM-00
	for <linux-mips@linux-mips.org>; Fri, 23 Sep 2005 02:24:17 +0200
Date:	Fri, 23 Sep 2005 02:24:17 +0200
To:	linux-mips@linux-mips.org
Subject: patch for 2.6.14-rc1 for sb1
Message-ID: <20050923002416.GB16161@codecarver>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="tNQTSEo8WG/FKZ8E"
Content-Disposition: inline
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag:	Get yourself a real email client. http://www.mutt.org/
X-mate:	Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.6+20040907i
From:	Peter 'p2' De Schrijver <p2@debian.org>
Return-Path: <p2@debian.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9032
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 3305
Lines: 115


--tNQTSEo8WG/FKZ8E
Content-Type: multipart/mixed; boundary="NKoe5XOeduwbEQHU"
Content-Disposition: inline


--NKoe5XOeduwbEQHU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

Attached is a patch which makes 2.6.14-rc1 work on the sb1 core. It's
nothing more then a rehash of some patches posted here earlier to make
recent 2.6 kernels work on sb1.=3D20

Thanks,

Peter (p2).

--=20
goa is a state of mind

--NKoe5XOeduwbEQHU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-sb1
Content-Transfer-Encoding: quoted-printable

diff -urN -x asm -x scripts -x config linux/arch/mips/kernel/cpu-probe.c li=
nux-my/arch/mips/kernel/cpu-probe.c
--- linux/arch/mips/kernel/cpu-probe.c	2005-08-16 19:50:43.000000000 +0200
+++ linux-my/arch/mips/kernel/cpu-probe.c	2005-09-22 13:09:29.000000000 +02=
00
@@ -612,6 +612,8 @@
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SB1:
 		c->cputype =3D CPU_SB1;
+		c->options &=3D ~MIPS_CPU_4KTLB;
+		c->options |=3D MIPS_CPU_TLB;
 #ifdef CONFIG_SB1_PASS_1_WORKAROUNDS
 		/* FPU in pass1 is known to have issues. */
 		c->options &=3D ~(MIPS_CPU_FPU | MIPS_CPU_32FPR);
diff -urN -x asm -x scripts -x config linux/arch/mips/mm/cache.c linux-my/a=
rch/mips/mm/cache.c
--- linux/arch/mips/mm/cache.c	2005-07-06 14:08:14.000000000 +0200
+++ linux-my/arch/mips/mm/cache.c	2005-09-22 13:28:21.000000000 +0200
@@ -122,6 +122,8 @@
     defined(CONFIG_CPU_MIPS64_R1) || defined(CONFIG_CPU_TX49XX) || \
     defined(CONFIG_CPU_RM7000) || defined(CONFIG_CPU_RM9000)
 		ld_mmu_r4xx0();
+#else
+		panic("Unknown CPU with r4k TLB");
 #endif
 	} else switch (current_cpu_data.cputype) {
 #ifdef CONFIG_CPU_R3000
diff -urN -x asm -x scripts -x config linux/arch/mips/sibyte/sb1250/irq.c l=
inux-my/arch/mips/sibyte/sb1250/irq.c
--- linux/arch/mips/sibyte/sb1250/irq.c	2005-07-11 12:03:30.000000000 +0200
+++ linux-my/arch/mips/sibyte/sb1250/irq.c	2005-09-22 13:26:21.000000000 +0=
200
@@ -53,7 +53,7 @@
 static unsigned int startup_sb1250_irq(unsigned int irq);
 static void ack_sb1250_irq(unsigned int irq);
 #ifdef CONFIG_SMP
-static void sb1250_set_affinity(unsigned int irq, unsigned long mask);
+static void sb1250_set_affinity(unsigned int irq, cpumask_t mask);
 #endif
=20
 #ifdef CONFIG_SIBYTE_HAS_LDT
@@ -117,23 +117,16 @@
 }
=20
 #ifdef CONFIG_SMP
-static void sb1250_set_affinity(unsigned int irq, unsigned long mask)
+static void sb1250_set_affinity(unsigned int irq, cpumask_t mask)
 {
 	int i =3D 0, old_cpu, cpu, int_on;
 	u64 cur_ints;
 	irq_desc_t *desc =3D irq_desc + irq;
 	unsigned long flags;
=20
-	while (mask) {
-		if (mask & 1) {
-			mask >>=3D 1;
-			break;
-		}
-		mask >>=3D 1;
-		i++;
-	}
+	i =3D first_cpu(mask);
=20
-	if (mask) {
+	if (cpus_weight(mask) > 1) {
 		printk("attempted to set irq affinity for irq %d to multiple CPUs\n", ir=
q);
 		return;
 	}

--NKoe5XOeduwbEQHU--

--tNQTSEo8WG/FKZ8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDM0swKLKVw/RurbsRAloPAKCJjt5lNI0pymFUrnOxMDz4FcE5VACgqNdh
UxD8F/Hx1t3omVy6TU5JScQ=
=uMum
-----END PGP SIGNATURE-----

--tNQTSEo8WG/FKZ8E--

From p2@debian.org Fri Sep 23 01:38:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Sep 2005 01:39:13 +0100 (BST)
Received: from NAT.office.mind.be ([62.166.230.82]:10133 "EHLO
	NAT.office.mind.be") by ftp.linux-mips.org with ESMTP
	id S8133378AbVIWAiu (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 23 Sep 2005 01:38:50 +0100
Received: (qmail 3919 invoked from network); 23 Sep 2005 00:38:49 -0000
Received: from localhost (HELO codecarver) ([127.0.0.1])
          (envelope-sender <p2@debian.org>)
          by localhost (qmail-ldap-1.03) with SMTP
          for <linux-mips@linux-mips.org>; 23 Sep 2005 00:38:49 -0000
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1EIbWp-0006DY-00
	for <linux-mips@linux-mips.org>; Fri, 23 Sep 2005 02:35:03 +0200
Date:	Fri, 23 Sep 2005 02:35:03 +0200
To:	linux-mips@linux-mips.org
Subject: patch for  2.6.14-rc1 for pcmcia on swarm
Message-ID: <20050923003502.GC16161@codecarver>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="f5QefDQHtn8hx44O"
Content-Disposition: inline
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag:	Get yourself a real email client. http://www.mutt.org/
X-mate:	Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.6+20040907i
From:	Peter 'p2' De Schrijver <p2@debian.org>
Return-Path: <p2@debian.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9033
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 18830
Lines: 714


--f5QefDQHtn8hx44O
Content-Type: multipart/mixed; boundary="fwqqG+mf3f7vyBCB"
Content-Disposition: inline


--fwqqG+mf3f7vyBCB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment
Content-Transfer-Encoding: quoted-printable

Hi,

The attached patch implements a hacked pcmcia driver for the Sibyte
swarm board. The driver has only been tested with storage cards (eg. CF
cards). It will probably not work with anything else.
The main problem is that the swarm pcmcia hardware only seems to be capable=
 of=20
generating memory accesses on the pcmcia bus. I don't know if this is a=20
hardware limition of the swarm board or just a lack of documentation. I=20
haven't found any documented way of generating a pcmcia i/o access on the=
=20
swarm board.=20

Cheers,

Peter (p2).

--=20
goa is a state of mind

--fwqqG+mf3f7vyBCB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-sb1-pcmcia
Content-Transfer-Encoding: quoted-printable

diff -urN -x asm -x scripts -x config linux/drivers/ide/legacy/ide-cs.c lin=
ux-my/drivers/ide/legacy/ide-cs.c
--- linux/drivers/ide/legacy/ide-cs.c	2005-09-15 10:54:18.000000000 +0200
+++ linux-my/drivers/ide/legacy/ide-cs.c	2005-09-22 18:06:17.000000000 +0200
@@ -186,10 +186,19 @@
 static int idecs_register(unsigned long io, unsigned long ctl, unsigned lo=
ng irq)
 {
     hw_regs_t hw;
+
+#ifdef CONFIG_PCMCIA_SIBYTE_SB1xxx_SOC
+	extern int sb_pcmcia_ack_intr(struct hwif_s *hwif);
+#endif
+
     memset(&hw, 0, sizeof(hw));
     ide_init_hwif_ports(&hw, io, ctl, NULL);
     hw.irq =3D irq;
     hw.chipset =3D ide_pci;
+
+#ifdef CONFIG_PCMCIA_SIBYTE_SB1xxx_SOC
+    hw.ack_intr=3Dsb_pcmcia_ack_intr;
+#endif
     return ide_register_hw_with_fixup(&hw, NULL, ide_undecoded_slave);
 }
=20
diff -urN -x asm -x scripts -x config linux/drivers/pcmcia/Kconfig linux-my=
/drivers/pcmcia/Kconfig
--- linux/drivers/pcmcia/Kconfig	2005-09-15 10:54:58.000000000 +0200
+++ linux-my/drivers/pcmcia/Kconfig	2005-09-22 16:50:27.000000000 +0200
@@ -221,6 +221,10 @@
 	tristate "NEC VRC4173 CARDU support"
 	depends on CPU_VR41XX && PCI && PCMCIA
=20
+config PCMCIA_SIBYTE_SB1xxx_SOC
+        tristate "SiByte SB1xxxx PCMCIA support"
+        depends on PCMCIA && SIBYTE_SB1xxx_SOC
+
 config OMAP_CF
 	tristate "OMAP CompactFlash Controller"
 	depends on PCMCIA && ARCH_OMAP16XX
diff -urN -x asm -x scripts -x config linux/drivers/pcmcia/Makefile linux-m=
y/drivers/pcmcia/Makefile
--- linux/drivers/pcmcia/Makefile	2005-09-17 02:38:10.000000000 +0200
+++ linux-my/drivers/pcmcia/Makefile	2005-09-22 16:50:43.000000000 +0200
@@ -35,6 +35,8 @@
 obj-$(CONFIG_PCMCIA_VRC4171)			+=3D vrc4171_card.o
 obj-$(CONFIG_PCMCIA_VRC4173)			+=3D vrc4173_cardu.o
 obj-$(CONFIG_OMAP_CF)				+=3D omap_cf.o
+obj-$(CONFIG_PCMCIA_SIBYTE_SB1xxx_SOC)          +=3D sibyte_generic.o
+
=20
 sa11xx_core-y					+=3D soc_common.o sa11xx_base.o
 pxa2xx_core-y					+=3D soc_common.o pxa2xx_base.o
diff -urN -x asm -x scripts -x config linux/drivers/pcmcia/pcmcia_resource.=
c linux-my/drivers/pcmcia/pcmcia_resource.c
--- linux/drivers/pcmcia/pcmcia_resource.c	2005-09-15 10:54:58.000000000 +0=
200
+++ linux-my/drivers/pcmcia/pcmcia_resource.c	2005-09-22 17:26:24.000000000=
 +0200
@@ -648,6 +648,7 @@
 		c->Copy =3D req->Copy;
 		pcmcia_write_cis_mem(s, 1, (base + CISREG_SCR)>>1, 1, &c->Copy);
 	}
+#ifdef CONFIG_PCMCIA_SIBYTE_SB1xxx_SOC
 	if (req->Present & PRESENT_OPTION) {
 		if (s->functions =3D=3D 1) {
 			c->Option =3D req->ConfigIndex & COR_CONFIG_MASK;
@@ -663,6 +664,7 @@
 		pcmcia_write_cis_mem(s, 1, (base + CISREG_COR)>>1, 1, &c->Option);
 		mdelay(40);
 	}
+#endif
 	if (req->Present & PRESENT_STATUS) {
 		c->Status =3D req->Status;
 		pcmcia_write_cis_mem(s, 1, (base + CISREG_CCSR)>>1, 1, &c->Status);
diff -urN -x asm -x scripts -x config linux/drivers/pcmcia/sibyte_generic.c=
 linux-my/drivers/pcmcia/sibyte_generic.c
--- linux/drivers/pcmcia/sibyte_generic.c	1970-01-01 01:00:00.000000000 +01=
00
+++ linux-my/drivers/pcmcia/sibyte_generic.c	2005-09-22 16:56:24.000000000 =
+0200
@@ -0,0 +1,558 @@
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/init.h>
+#include <linux/config.h>
+#include <linux/cpufreq.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/timer.h>
+#include <linux/mm.h>
+#include <linux/notifier.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/device.h>
+
+#include <linux/ide.h>
+
+#include <pcmcia/version.h>
+#include <pcmcia/cs_types.h>
+#include <pcmcia/cs.h>
+#include <pcmcia/ss.h>
+#include <pcmcia/bulkmem.h>
+#include <pcmcia/cistpl.h>
+#include "cs_internal.h"
+
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/system.h>
+
+#include <asm/sibyte/board.h>
+#include <asm/sibyte/sb1250_regs.h>
+#include <asm/sibyte/sb1250_scd.h>
+#include <asm/sibyte/sb1250_int.h>
+#include <asm/sibyte/sb1250_genbus.h>
+
+#define IO_MAP_SIZE	0x1000
+
+#define CARDPRESENT(s) (((s) & (M_PCMCIA_STATUS_CD1 | \
+			M_PCMCIA_STATUS_CD2)) =3D=3D 0)
+
+#define POWERON(s)	((s) & (M_PCMCIA_STATUS_3VEN | \
+			M_PCMCIA_STATUS_5VEN))
+
+#define SIBYTE_PCMCIA_POLL_PERIOD (2*HZ)
+
+DECLARE_MUTEX(pcmcia_sockets_lock);
+
+struct sibyte_pcmcia_socket {
+	struct pcmcia_socket socket;
+
+	struct device *dev;
+	int irq;
+
+	int status;
+	socket_state_t cs_state;
+
+	unsigned short	spd_io[MAX_IO_WIN];
+	unsigned short	spd_mem[MAX_WIN];
+
+	struct resource	res_skt;
+	struct resource	res_io;
+	struct resource	res_mem;
+
+	void *virt_io;
+	ioaddr_t phys_io;
+	unsigned int phys_mem;
+	unsigned short	speed_io, speed_attr, speed_mem;
+
+	unsigned int irq_state;
+
+	struct timer_list       poll_timer;
+
+};
+
+struct sibyte_pcmcia_socket sibyte_pcmcia_socket[1];
+#define PCMCIA_SOCKET(x) (sibyte_pcmcia_socket+x);
+
+static unsigned int sibyte_pcmcia_skt_state(struct sibyte_pcmcia_socket *s=
kt)
+{
+	u32 stat;
+	unsigned int status=3D0;
+
+	stat=3Dcsr_in32(IOADDR(A_IO_PCMCIA_STATUS));
+=09
+
+	if(CARDPRESENT(status))=20
+		status=3DSS_DETECT;
+	if(!(stat & M_PCMCIA_STATUS_VS1))
+		status|=3DSS_3VCARD;
+	if(!(stat & M_PCMCIA_STATUS_VS2))
+		status|=3DSS_XVCARD;
+	if(stat & M_PCMCIA_STATUS_WP)
+		status|=3DSS_WRPROT;
+	if(stat & M_PCMCIA_STATUS_RDY)
+		status|=3DSS_READY;
+	if(stat & POWERON(status))
+		status|=3DSS_POWERON;
+	if(stat & (M_PCMCIA_STATUS_CDCHG | M_PCMCIA_STATUS_WPCHG |=20
+		   M_PCMCIA_STATUS_RDYCHG))
+		status|=3DSS_STSCHG;
+
+
+	return status;
+}
+
+static DEFINE_SPINLOCK(status_lock);
+
+static void sibyte_check_status(struct sibyte_pcmcia_socket *skt)
+{
+	unsigned int events;
+
+	do {
+		unsigned int status;
+		unsigned long flags;
+
+		status=3Dsibyte_pcmcia_skt_state(skt);
+
+		spin_lock_irqsave(&status_lock, flags);
+		events =3D (status ^ skt->status) & skt->cs_state.csc_mask;
+		skt->status=3Dstatus;
+		spin_unlock_irqrestore(&status_lock, flags);
+
+		if(events)
+			pcmcia_parse_events(&skt->socket, events);
+	} while(events);
+}
+
+
+static void sibyte_pcmcia_poll_event(unsigned long context)
+{
+	struct sibyte_pcmcia_socket *skt=3D
+		(struct sibyte_pcmcia_socket *)context;
+
+	mod_timer(&skt->poll_timer, jiffies + SIBYTE_PCMCIA_POLL_PERIOD);
+
+	sibyte_check_status(skt);
+}
+
+
+static irqreturn_t sibyte_pcmcia_interrupt(int irq, void *context,=20
+					   struct pt_regs *regs)
+{
+	struct sibyte_pcmcia_socket *skt=3D
+		(struct sibyte_pcmcia_socket *)context;
+
+	sibyte_check_status(skt);
+
+	return IRQ_HANDLED;
+}
+	=09
+/* Note that Vpp is never set. There are normally 2 lines to the pcmcia
+ * power controller to control the Vpp level. The SB1250 PCMCIA control re=
gister
+ * however provides only 1 bit to control Vpp. Any information on the exact
+ * behaviour welcome.
+ */
+static int sibyte_pcmcia_config_skt(struct sibyte_pcmcia_socket *skt,=20
+				    socket_state_t *state)
+{
+	u32 config;
+
+	config=3Dcsr_in32(IOADDR(A_IO_PCMCIA_CFG));
+
+	config &=3D ~(M_PCMCIA_CFG_3VEN | M_PCMCIA_CFG_5VEN);
+
+	switch(state->Vcc) {
+		case 33:
+			config|=3DM_PCMCIA_CFG_3VEN;
+			break;
+		case 50:
+			config|=3DM_PCMCIA_CFG_5VEN;
+			break;
+	}
+
+	if(state->csc_mask & SS_DETECT)
+		config&=3D~M_PCMCIA_CFG_CDMASK;
+	else
+		config|=3DM_PCMCIA_CFG_CDMASK;
+
+	config &=3D ~M_PCMCIA_CFG_RESET;
+	if(state->flags & SS_RESET) {
+		config|=3DM_PCMCIA_CFG_RESET;
+	}
+
+	csr_out32(config,IOADDR(A_IO_PCMCIA_CFG));
+
+	return 0;
+}
+
+static int sibyte_pcmcia_sock_init(struct pcmcia_socket *sock)
+{
+	return 0;
+}
+
+
+static int sibyte_pcmcia_get_status(struct pcmcia_socket *sock,=20
+				    unsigned int *status)
+{
+        struct sibyte_pcmcia_socket *skt=3D
+                (struct sibyte_pcmcia_socket *)sock;
+
+	skt->status=3Dsibyte_pcmcia_skt_state(skt);
+	*status=3Dskt->status;
+
+	return 0;
+}
+
+static int sibyte_pcmcia_get_socket(struct pcmcia_socket *sock,=20
+				    socket_state_t *state)
+{
+        struct sibyte_pcmcia_socket *skt=3D
+                (struct sibyte_pcmcia_socket *)sock;
+
+	*state=3Dskt->cs_state;
+
+	return 0;
+}
+
+static int sibyte_pcmcia_set_socket(struct pcmcia_socket *sock,=20
+				    socket_state_t *state)
+{
+        struct sibyte_pcmcia_socket *skt=3D
+                (struct sibyte_pcmcia_socket *)sock;
+
+	return sibyte_pcmcia_config_skt(skt,state);
+}
+
+static int sibyte_pcmcia_set_io_map(struct pcmcia_socket *sock,=20
+			     	    struct pccard_io_map *io)
+{
+        struct sibyte_pcmcia_socket *skt=3D
+                (struct sibyte_pcmcia_socket *)sock;
+	unsigned int speed;
+	u32 config;
+
+	if (io->map >=3D MAX_IO_WIN) {
+		return -1;
+	}
+
+	if (io->flags & MAP_ACTIVE) {
+		speed=3D(io->speed > 0) ? io->speed : 255;
+		skt->spd_io[io->map]=3Dspeed;
+	}
+
+	config=3Dcsr_in32(IOADDR(A_IO_PCMCIA_CFG));
+        config&=3D~M_PCMCIA_CFG_ATTRMEM;
+        csr_out32(config,IOADDR(A_IO_PCMCIA_CFG));
+
+	io->start=3D(ioaddr_t)(u32)skt->virt_io;
+	io->stop=3Dio->start + IO_MAP_SIZE;
+
+	return 0;
+}
+
+static int sibyte_pcmcia_set_mem_map(struct pcmcia_socket *sock,=20
+				     struct pccard_mem_map *io)
+{
+        struct sibyte_pcmcia_socket *skt=3D
+                (struct sibyte_pcmcia_socket *)sock;
+	u32 config;
+	unsigned int speed=3Dio->speed;
+
+	if(io->map >=3D MAX_WIN) {
+		return -1;
+	}
+
+	config=3Dcsr_in32(IOADDR(A_IO_PCMCIA_CFG));
+	if(io->flags & MAP_ATTRIB) {
+		config|=3DM_PCMCIA_CFG_ATTRMEM;
+	}
+	else {
+		config&=3D~M_PCMCIA_CFG_ATTRMEM;
+	}
+	csr_out32(config,IOADDR(A_IO_PCMCIA_CFG));
+
+	skt->spd_mem[io->map]=3Dspeed;
+
+	io->static_start=3Dskt->phys_mem;
+
+	return 0;
+}
+
+/* the following functions are a gross layer violation. the pcmcia layer h=
ooks=20
+ * into the IDE layer to fiddle around with the config register.
+ */
+
+int sb_pcmcia_ack_intr(struct hwif_s *hwif)
+{
+
+	csr_out32(1 << K_GPIO_PC_READY, IOADDR(A_GPIO_CLR_EDGE));
+
+	return 1;
+}
+
+static void sibyte_pcmcia_selectproc(ide_drive_t *drive)
+{
+        u32 config;
+
+	config=3Dcsr_in32(IOADDR(A_IO_PCMCIA_CFG));
+	config&=3D~M_PCMCIA_CFG_ATTRMEM;
+	csr_out32(config,IOADDR(A_IO_PCMCIA_CFG));
+
+}
+
+static int sibyte_pc_prep_ide(void *iobase)
+{
+	int i;
+	ide_hwif_t *hwif =3D NULL;
+
+	/* Stake early claim on an ide_hwif */
+	for (i =3D 0; i < MAX_HWIFS; i++) {
+		if (!ide_hwifs[i].io_ports[IDE_DATA_OFFSET]) {
+			hwif =3D &ide_hwifs[i];=20
+			break;
+		}
+	}
+	if (hwif =3D=3D NULL) {
+		 printk("No space for SiByte onboard PCMCIA driver in ide_hwifs[].  Not =
enabled.\n");
+		 return 1;
+	}
+
+	/*
+	 * Prime the hwif with port values, so when a card is
+	 * detected, the 'io_offset' from the capabilities will lead
+	 * it here
+	 */
+	hwif->hw.io_ports[IDE_DATA_OFFSET]    =3D iobase + (0);
+	hwif->hw.io_ports[IDE_ERROR_OFFSET]   =3D iobase + (1);
+	hwif->hw.io_ports[IDE_NSECTOR_OFFSET] =3D iobase + (2);
+	hwif->hw.io_ports[IDE_SECTOR_OFFSET]  =3D iobase + (3);
+	hwif->hw.io_ports[IDE_LCYL_OFFSET]    =3D iobase + (4);
+	hwif->hw.io_ports[IDE_HCYL_OFFSET]    =3D iobase + (5);
+	hwif->hw.io_ports[IDE_SELECT_OFFSET]  =3D iobase + (6);
+	hwif->hw.io_ports[IDE_STATUS_OFFSET]  =3D iobase + (7);
+	hwif->hw.io_ports[IDE_CONTROL_OFFSET] =3D iobase + (6); /* XXXKW ? */
+	hwif->hw.ack_intr                     =3D sb_pcmcia_ack_intr;
+	hwif->selectproc                      =3D sibyte_pcmcia_selectproc;
+	hwif->hold                            =3D 1;
+	hwif->mmio                            =3D 2;
+
+	printk("SiByte onboard PCMCIA-IDE configured as device %i\n", i);
+
+	return 0;
+}
+
+/* end of hack */
+static struct pccard_operations sibyte_pcmcia_operations =3D {
+        .init                   =3D sibyte_pcmcia_sock_init,
+	.get_status             =3D sibyte_pcmcia_get_status,
+	.get_socket             =3D sibyte_pcmcia_get_socket,
+	.set_socket             =3D sibyte_pcmcia_set_socket,
+	.set_io_map             =3D sibyte_pcmcia_set_io_map,
+	.set_mem_map            =3D sibyte_pcmcia_set_mem_map,
+};
+
+static int sibyte_pcmcia_sock_hw_init(struct sibyte_pcmcia_socket *skt)
+{
+
+	u32 status, config;
+	u32 gpio_ctrl;
+
+	status=3Dcsr_in32(IOADDR(A_IO_PCMCIA_STATUS));
+
+	config =3D M_PCMCIA_CFG_CDMASK | M_PCMCIA_CFG_WPMASK |=20
+		 M_PCMCIA_CFG_RDYMASK;
+
+	csr_out32(config,IOADDR(A_IO_PCMCIA_CFG));
+
+	gpio_ctrl=3Dcsr_in32(IOADDR(A_GPIO_INT_TYPE));
+	gpio_ctrl&=3D~M_GPIO_INTR_TYPEX(K_GPIO_PC_READY);
+	gpio_ctrl|=3DV_GPIO_INTR_TYPEX(K_GPIO_PC_READY,=20
+				     K_GPIO_INTR_EDGE);
+
+	csr_out32(gpio_ctrl, IOADDR(A_GPIO_INT_TYPE));
+	csr_out32(1 << K_GPIO_PC_READY, IOADDR(A_GPIO_CLR_EDGE));
+
+	gpio_ctrl=3Dcsr_in32(IOADDR(A_GPIO_INPUT_INVERT));
+	gpio_ctrl|=3D1 << K_GPIO_PC_READY;
+	csr_out32(gpio_ctrl, IOADDR(A_GPIO_INPUT_INVERT));
+
+	if (request_irq(K_INT_PCMCIA, sibyte_pcmcia_interrupt, 0,=20
+			"pcmcia", skt))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int sibyte_pcmcia_socket_probe(struct device *dev, u32 base, u32 si=
ze)
+{
+	int ret;
+	struct sibyte_pcmcia_socket *skt=3DPCMCIA_SOCKET(0);
+
+	skt->socket.ops=3D&sibyte_pcmcia_operations;
+	skt->socket.resource_ops=3D&pccard_static_ops;
+	skt->socket.owner=3DTHIS_MODULE;
+	skt->socket.dev.dev=3Ddev;
+
+	skt->irq=3DK_INT_PC_READY;
+	skt->dev=3Ddev;
+
+	init_timer(&skt->poll_timer);
+	skt->poll_timer.function=3Dsibyte_pcmcia_poll_event;
+	skt->poll_timer.data=3D(unsigned long)skt;
+	skt->poll_timer.expires=3Djiffies+SIBYTE_PCMCIA_POLL_PERIOD;
+
+	skt->res_skt.start=3Dbase;
+	skt->res_skt.end=3Dbase+size;
+	skt->res_skt.name=3D"PCMCIA socket 0";
+	skt->res_skt.flags=3DIORESOURCE_MEM;
+	ret=3Drequest_resource(&iomem_resource, &skt->res_skt);
+	if(ret)
+		goto out_err_1;
+
+	skt->res_io.name=3D"io";
+	skt->res_io.flags=3DIORESOURCE_MEM | IORESOURCE_BUSY;
+	skt->res_io.start=3Dbase;
+	skt->res_io.end=3Dbase+IO_MAP_SIZE-1;
+	ret=3Drequest_resource(&skt->res_skt, &skt->res_io);
+	if(ret)
+		goto out_err_2;
+=09
+	skt->res_mem.name=3D"memory";
+	skt->res_mem.flags=3DIORESOURCE_MEM;
+	skt->res_mem.start=3Dbase+IO_MAP_SIZE;
+	skt->res_mem.end=3Dbase+size;
+	ret=3Drequest_resource(&skt->res_skt, &skt->res_mem);
+	if(ret)
+		goto out_err_3;
+=09
+	skt->virt_io=3D(void *)(ioremap((phys_t)base, IO_MAP_SIZE) -
+				(u32)mips_io_port_base);
+	skt->phys_mem=3Dbase;
+
+	skt->socket.features=3DSS_CAP_STATIC_MAP|SS_CAP_PCCARD|SS_CAP_PAGE_REGS|
+			     SS_CAP_MEM_ALIGN;
+	skt->socket.irq_mask=3D0;
+	skt->socket.map_size=3Dsize;
+	skt->socket.pci_irq=3Dskt->irq;
+	skt->socket.io_offset=3D(unsigned long)skt->virt_io;
+
+	skt->status=3Dsibyte_pcmcia_skt_state(skt);
+
+	ret=3Dpcmcia_register_socket(&skt->socket);
+	if(ret)
+		goto out_err_4;
+=09
+	ret=3Dsibyte_pcmcia_sock_hw_init(skt);
+	if(ret)
+		goto out_err;
+
+	WARN_ON(skt->socket.sock !=3D 0);
+
+	sibyte_pc_prep_ide(skt->virt_io);
+
+	dev_set_drvdata(dev, skt);
+
+	add_timer(&skt->poll_timer);
+
+	return 0;
+
+out_err:
+	pcmcia_unregister_socket(&skt->socket);
+out_err_4:
+	release_resource(&skt->res_mem);
+out_err_3:
+	release_resource(&skt->res_io);
+out_err_2:
+	release_resource(&skt->res_skt);
+out_err_1:
+	del_timer_sync(&skt->poll_timer);
+	flush_scheduled_work();
+
+	return ret;
+}
+
+
+
+static int sibyte_pcmcia_probe(struct device *dev)
+{
+	u64 cfg;
+	u32 pcmcia_size,pcmcia_base,addr;
+	int ret;
+
+	down(&pcmcia_sockets_lock);
+	cfg=3D__raw_readq(IOADDR(A_SCD_SYSTEM_CFG));
+	if(!(cfg & M_SYS_PCMCIA_ENABLE)) {
+		printk(KERN_INFO "chip not configured for PCMCIA\n");
+		return -ENODEV;
+	}
+
+	addr=3DA_IO_EXT_REG(R_IO_EXT_REG(R_IO_EXT_MULT_SIZE, PCMCIA_CS));
+	pcmcia_size=3D(G_IO_MULT_SIZE(csr_in32(IOADDR(addr))) + 1)<<S_IO_REGSIZE;
+
+	addr=3DA_IO_EXT_REG(R_IO_EXT_REG(R_IO_EXT_START_ADDR, PCMCIA_CS));
+	pcmcia_base=3DG_IO_START_ADDR(csr_in32(IOADDR(addr))) << S_IO_ADDRBASE;=
=09
+
+	ret=3Dsibyte_pcmcia_socket_probe(dev, pcmcia_base, pcmcia_size);
+
+	up(&pcmcia_sockets_lock);
+
+	return ret;
+}
+
+int sibyte_pcmcia_remove(struct device *dev)
+{
+	struct sibyte_pcmcia_socket *skt=3D(struct sibyte_pcmcia_socket *)
+					  dev_get_drvdata(dev);
+        down(&pcmcia_sockets_lock);
+
+	dev_set_drvdata(dev, NULL);
+	del_timer_sync(&skt->poll_timer);
+	pcmcia_unregister_socket(&skt->socket);
+	flush_scheduled_work();
+	sibyte_pcmcia_config_skt(skt,&dead_socket);
+	iounmap(skt->virt_io);
+	skt->virt_io =3D NULL;
+
+	up(&pcmcia_sockets_lock);
+	return 0;
+}
+
+
+static struct device_driver sibyte_pcmcia_driver =3D {
+	.probe 		=3D sibyte_pcmcia_probe,
+	.remove 	=3D sibyte_pcmcia_remove,
+	.name		=3D "sb1xxx-pcmcia",
+	.bus		=3D &platform_bus_type,
+};
+
+static struct platform_device sibyte_pcmcia_device =3D {
+	.name =3D "sb1xxx-pcmcia",
+	.id =3D 0,
+};
+
+static int __init sibyte_pcmcia_init(void)
+{
+	int err;
+
+	err=3Ddriver_register(&sibyte_pcmcia_driver);
+	if(err)
+		return err;
+
+	platform_device_register(&sibyte_pcmcia_device);
+
+	return 0;
+}
+
+static void __exit sibyte_pcmcia_exit(void)
+{
+	driver_unregister(&sibyte_pcmcia_driver);
+	platform_device_unregister(&sibyte_pcmcia_device);
+}
+
+
+EXPORT_SYMBOL(sb_pcmcia_ack_intr);
+
+module_init(sibyte_pcmcia_init);
+module_exit(sibyte_pcmcia_exit);
+
diff -urN -x asm -x scripts -x config linux/include/asm-mips/ide.h linux-my=
/include/asm-mips/ide.h
--- linux/include/asm-mips/ide.h	2004-11-24 19:35:14.000000000 +0100
+++ linux-my/include/asm-mips/ide.h	2005-09-22 17:47:08.000000000 +0200
@@ -10,4 +10,9 @@
=20
 #include <ide.h>
=20
+#ifdef CONFIG_PCMCIA_SIBYTE_SB1xxx_SOC
+#define IDE_ARCH_ACK_INTR
+#define ide_ack_intr(hwif)      ((hwif)->hw.ack_intr ? (hwif)->hw.ack_intr=
(hwif) : 1)
+#endif
+
 #endif /* __ASM_IDE_H */

--fwqqG+mf3f7vyBCB--

--f5QefDQHtn8hx44O
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDM022KLKVw/RurbsRAvIPAJ9ROgR/R/5/nh6uUw+t7aCrUlDugwCdGBeg
/av2T3PeAjA2ezunZ9nBWE4=
=SIfv
-----END PGP SIGNATURE-----

--f5QefDQHtn8hx44O--

From p2@debian.org Sat Sep 24 23:01:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Sep 2005 23:01:16 +0100 (BST)
Received: from NAT.office.mind.be ([62.166.230.82]:49044 "EHLO
	NAT.office.mind.be") by ftp.linux-mips.org with ESMTP
	id S8133448AbVIXWBA (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Sat, 24 Sep 2005 23:01:00 +0100
Received: (qmail 11431 invoked from network); 24 Sep 2005 22:00:56 -0000
Received: from localhost (HELO codecarver) ([127.0.0.1])
          (envelope-sender <p2@debian.org>)
          by localhost (qmail-ldap-1.03) with SMTP
          for <linux-mips@linux-mips.org>; 24 Sep 2005 22:00:56 -0000
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1EJI19-0002EG-00
	for <linux-mips@linux-mips.org>; Sat, 24 Sep 2005 23:57:11 +0200
Date:	Sat, 24 Sep 2005 23:57:10 +0200
To:	linux-mips@linux-mips.org
Subject: Bus error on sb1250
Message-ID: <20050924215710.GA6310@codecarver>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag:	Get yourself a real email client. http://www.mutt.org/
X-mate:	Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.6+20040907i
From:	Peter 'p2' De Schrijver <p2@debian.org>
Return-Path: <p2@debian.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9034
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 4005
Lines: 119


--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I'm seeing some strange bus errors when trying to get the Fore
ForeRunner PCA-200EPC card to work on the sibyte swarm. The driver polls
a register on this card for status information. This triggers a bus
error once in a while. This happens regardless if the card is attached
to the PCI bus of the sb1250 or to the PCI bus behind the Alliance HT -
PCI bridge.=20

The bus error dump looks as follows :

DBE physical address: 0041000400
Data bus error, epc =3D=3D c12f8214, ra =3D=3D c13533d4
Oops in arch/mips/kernel/traps.c::do_be, line 361[#1]:
Cpu 0
$ 0   : 00000000 00000004 c12f820c c12fac20
$ 4   : c1400404 ffffffff 00ff0000 00000000
$ 8   : 00000000 00000000 00000000 8d903d48
$12   : 00000010 8d903c54 00000000 ffffffff
$16   : fffffed8 80350000 fffd59a9 c1350000
$20   : 8d410000 c1400404 803a7900 01000000
$24   : ffffffff 00000004
$28   : 8d902000 8d903cd8 c1300000 c13533d4
Hi    : 00040fff
Lo    : fb4d8000
epc   : c12f8214 fore200e_pca_read+0x8/0x54 [fore_200e]     Not tainted
ra    : c13533d4 fore200e_monitor_getc+0x9c/0x10c [fore_200e]
Status: 10001f03    KERNEL EXL IE
Cause : 0080801c
PrId  : 01040102
Modules linked in: fore_200e videodev nfsd exportfs lockd sunrpc md5 ipv6 i=
de_cs
eth1394 ohci1394 ieee1394 ehci_hcd usbhid ohci_hcd usbcore clip atm ide_cd=
=20
cdrom genrtc
Process insmod (pid: 2473, threadinfo=3D8d902000, task=3D8f66c500)
Stack : 000024ae 8d410020 c1300000 80201ac4 c1353338 8d903d41 8d410000 c135=
0000
        01000000 8d410020 c1300000 80201ac4 c1353690 c13535dc 803a892a 1000=
1f01
        000056c0 00000000 00000000 2ac23ae0 81298ea0 00000030 8d903db4 c12f=
e220
        ffffffff ffffffff 0d676f20 35366330 0d003dd0 8d410029 ffffffff ffff=
ffff
        ffffffff 00000002 c1300000 41000000 0000000a ffffffff ffffffff 0000=
0002
        ...=20
Call Trace:=20
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<80201ac4>] sprintf+0x0/0x3c
 [<c1353338>] fore200e_monitor_getc+0x0/0x10c [fore_200e]
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<80201ac4>] sprintf+0x0/0x3c
 [<c1353690>] fore200e_init+0x24c/0xd38 [fore_200e]
 [<c13535dc>] fore200e_init+0x198/0xd38 [fore_200e]
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<80201ac4>] sprintf+0x0/0x3c
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<80201ac4>] sprintf+0x0/0x3c
 [<c1300000>] inet6_release+0x0/0x78 [ipv6]
 [<c12f9f34>] fore200e_pca_detect+0x150/0x204 [fore_200e]
 [<80130000>] release_resource+0x1c/0xbc
 [<8021386c>] pci_device_probe+0x80/0xa4
 [<802137dc>] pci_bus_match+0x18/0x28
 [<8025427c>] driver_probe_device+0x58/0xf0
 [<80314dd0>] klist_next+0x4c/0x80
 [<80254490>] __driver_attach+0x9c/0xc4
 [<802543f4>] __driver_attach+0x0/0xc4
 [<802534b4>] next_device+0x10/0x2c
 [<802543f4>] __driver_attach+0x0/0xc4
 [<80253520>] bus_for_each_dev+0x50/0xb4
 [<80130000>] release_resource+0x1c/0xbc
 [<801fd860>] kobject_register+0x48/0x90
 [<80253b44>] bus_add_driver+0x9c/0x1a4
 [<80213400>] pci_register_driver+0x7c/0xcc
 [<801239d8>] default_wake_function+0x0/0x20
 [<c13542b0>] fore200e_module_init+0x134/0x1ac [fore_200e]
 [<80143634>] kthread_stop+0xc0/0x13c
 [<8014c778>] sys_init_module+0x158/0x39c
 [<8014c740>] sys_init_module+0x120/0x39c
 [<80175f44>] filp_close+0x6c/0xb0
 [<8010bacc>] stack_done+0x20/0x3c
 [<8010bacc>] stack_done+0x20/0x3c


Code: 00000000  8c850000  3c0600ff <30a4ff00> 00051600  00a61824 00052e02 =
=20
      00042200  00441025

Any idea why this might be happening ?

Thanks,

Peter (p2).

--=20
goa is a state of mind

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDNcu2KLKVw/RurbsRAuVaAJ0UXb2xncNAeTzBtfrqyyPD06eGlACdFHwp
xqx9nXgrTwHtEikmNSjuGaI=
=hWSz
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--

From p2@debian.org Sun Sep 25 15:10:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Sep 2005 15:10:52 +0100 (BST)
Received: from NAT.office.mind.be ([62.166.230.82]:21960 "EHLO
	NAT.office.mind.be") by ftp.linux-mips.org with ESMTP
	id S8133466AbVIYOKe (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Sun, 25 Sep 2005 15:10:34 +0100
Received: (qmail 28198 invoked from network); 25 Sep 2005 14:10:32 -0000
Received: from localhost (HELO codecarver) ([127.0.0.1])
          (envelope-sender <p2@debian.org>)
          by localhost (qmail-ldap-1.03) with SMTP
          for <linux-mips@linux-mips.org>; 25 Sep 2005 14:10:32 -0000
Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian))
	id 1EJWp0-0006oz-00
	for <linux-mips@linux-mips.org>; Sun, 25 Sep 2005 15:45:38 +0200
Date:	Sun, 25 Sep 2005 15:45:38 +0200
To:	linux-mips@linux-mips.org
Subject: Re: Bus error on sb1250
Message-ID: <20050925134538.GA25829@codecarver>
Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org
References: <20050924215710.GA6310@codecarver>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09"
Content-Disposition: inline
In-Reply-To: <20050924215710.GA6310@codecarver>
X-Answer: 42
X-Operating-system: Debian GNU/Linux
X-Message-Flag:	Get yourself a real email client. http://www.mutt.org/
X-mate:	Mate, man gewoehnt sich an alles
User-Agent: Mutt/1.5.6+20040907i
From:	Peter 'p2' De Schrijver <p2@debian.org>
Return-Path: <p2@debian.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9035
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: p2@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2679
Lines: 95


--CblX+4bnyfN0pR09
Content-Type: multipart/mixed; boundary="K8nIJk4ghYZn606h"
Content-Disposition: inline


--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Sat, Sep 24, 2005 at 11:57:10PM +0200, Peter 'p2' De Schrijver wrote:
> Hi,
>=20
> I'm seeing some strange bus errors when trying to get the Fore
> ForeRunner PCA-200EPC card to work on the sibyte swarm. The driver polls
> a register on this card for status information. This triggers a bus
> error once in a while. This happens regardless if the card is attached
> to the PCI bus of the sb1250 or to the PCI bus behind the Alliance HT -
> PCI bridge.=20
>=20

Thanks to Maciej, I found the problem. The device apparently does not
always react in time for the sb1250 PCI host. Changing TrdyTimeout to
0xff fixes the problem for the 32bit PCI slots. I need to find the
equivalent register on the SP1011 bridge to fix the problem for the
64bit PCI slots. Patch attached.

Cheers,

Peter (p2).

--
goa is a state of mind

--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-pci
Content-Transfer-Encoding: quoted-printable

--- linux/include/linux/pci_ids.h	2005-09-15 10:56:21.000000000 +0200
+++ linux-my/include/linux/pci_ids.h	2005-09-25 15:10:53.000000000 +0200
@@ -2192,6 +2192,7 @@
 #define PCI_DEVICE_ID_FARSITE_TE1C      0x1612
=20
 #define PCI_VENDOR_ID_SIBYTE		0x166d
+#define PCI_DEVICE_ID_BCM1250_PCI	0x0001
 #define PCI_DEVICE_ID_BCM1250_HT	0x0002
=20
 #define PCI_VENDOR_ID_NETCELL		0x169c
--- linux/arch/mips/pci/fixup-sb1250.c	2004-12-18 23:28:20.000000000 +0100
+++ linux-my/arch/mips/pci/fixup-sb1250.c	2005-09-25 15:25:02.000000000 +02=
00
@@ -20,5 +20,22 @@
 {
 	dev->class =3D PCI_CLASS_BRIDGE_PCI << 8;
 }
+
+/*
+ * Set PCI Trdy timeout to 0xff clock cycles
+ */
+static void __init quirk_sb1250_pci(struct pci_dev *dev)
+{
+	u32 pci_timeout;
+
+	pci_read_config_dword(dev, 0x40, &pci_timeout);
+	pci_timeout|=3D0xff;
+	pci_write_config_dword(dev,0x40,pci_timeout);
+}
+
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_HT,
 			quirk_sb1250_ht);
+
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
+			quirk_sb1250_pci);
+

--K8nIJk4ghYZn606h--

--CblX+4bnyfN0pR09
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDNqoBKLKVw/RurbsRAhUnAKCEqDbZG71FcEKFAmcKIbzGqF7lAACbB+3+
RvIBYfIm+mTtzWsOI0yHF0Q=
=tIJ3
-----END PGP SIGNATURE-----

--CblX+4bnyfN0pR09--

From anemo@mba.ocn.ne.jp Sun Sep 25 16:19:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Sep 2005 16:19:37 +0100 (BST)
Received: from mba.ocn.ne.jp ([210.190.142.172]:35807 "HELO smtp.mba.ocn.ne.jp")
	by ftp.linux-mips.org with SMTP id S8133472AbVIYPTU (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Sun, 25 Sep 2005 16:19:20 +0100
Received: from localhost (p6250-ipad30funabasi.chiba.ocn.ne.jp [221.184.81.250])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 3AD2C4E9E; Mon, 26 Sep 2005 00:19:17 +0900 (JST)
Date:	Mon, 26 Sep 2005 00:17:53 +0900 (JST)
Message-Id: <20050926.001753.74752084.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: add __iomem to ioremap
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9036
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 2574
Lines: 72

Some function like iounmap, read[bwlq], etc. have been using __iomem
attribute, but ioremap does not use it.  Here is a patch to add
__iomem to ioremap family.  This would kill some sparse warnings.


diff -ur /home/cvs/linux-mips/include/asm-mips/io.h linux/include/asm-mips/io.h
--- linux-mips/include/asm-mips/io.h	2005-09-25 00:12:39.000000000 +0900
+++ linux/include/asm-mips/io.h	2005-09-25 23:08:18.930898136 +0900
@@ -203,10 +203,10 @@
  */
 #define page_to_phys(page)	((dma_addr_t)page_to_pfn(page) << PAGE_SHIFT)
 
-extern void * __ioremap(phys_t offset, phys_t size, unsigned long flags);
+extern void __iomem * __ioremap(phys_t offset, phys_t size, unsigned long flags);
 extern void __iounmap(volatile void __iomem *addr);
 
-static inline void * __ioremap_mode(phys_t offset, unsigned long size,
+static inline void __iomem * __ioremap_mode(phys_t offset, unsigned long size,
 	unsigned long flags)
 {
 #define __IS_LOW512(addr) (!((phys_t)(addr) & (phys_t) ~0x1fffffffULL))
@@ -220,7 +220,7 @@
 		 */
 		if (flags == _CACHE_UNCACHED)
 			base = (u64) IO_BASE;
-		return (void *) (unsigned long) (base + offset);
+		return (void __iomem *) (unsigned long) (base + offset);
 	} else if (__builtin_constant_p(offset) &&
 		   __builtin_constant_p(size) && __builtin_constant_p(flags)) {
 		phys_t phys_addr, last_addr;
@@ -238,7 +238,7 @@
 		 */
 		if (__IS_LOW512(phys_addr) && __IS_LOW512(last_addr) &&
 		    flags == _CACHE_UNCACHED)
-			return (void *)CKSEG1ADDR(phys_addr);
+			return (void __iomem *)CKSEG1ADDR(phys_addr);
 
 	}
 
diff -ur linux-mips/arch/mips/mm/ioremap.c linux/arch/mips/mm/ioremap.c
--- linux-mips/arch/mips/mm/ioremap.c	2005-07-03 01:09:48.000000000 +0900
+++ linux/arch/mips/mm/ioremap.c	2005-09-25 23:09:24.944862488 +0900
@@ -117,7 +117,7 @@
 
 #define IS_LOW512(addr) (!((phys_t)(addr) & (phys_t) ~0x1fffffffULL))
 
-void * __ioremap(phys_t phys_addr, phys_t size, unsigned long flags)
+void __iomem * __ioremap(phys_t phys_addr, phys_t size, unsigned long flags)
 {
 	struct vm_struct * area;
 	unsigned long offset;
@@ -137,7 +137,7 @@
 	 */
 	if (IS_LOW512(phys_addr) && IS_LOW512(last_addr) &&
 	    flags == _CACHE_UNCACHED)
-		return (void *) CKSEG1ADDR(phys_addr);
+		return (void __iomem *) CKSEG1ADDR(phys_addr);
 
 	/*
 	 * Don't allow anybody to remap normal RAM that we're using..
@@ -173,7 +173,7 @@
 		return NULL;
 	}
 
-	return (void *) (offset + (char *)addr);
+	return (void __iomem *) (offset + (char *)addr);
 }
 
 #define IS_KSEG1(addr) (((unsigned long)(addr) & ~0x1fffffffUL) == CKSEG1)

---
Atsushi Nemoto

From vagabon.xyz@gmail.com Mon Sep 26 08:06:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 08:07:12 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.200]:2705 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S8133507AbVIZHG5 convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 08:06:57 +0100
Received: by zproxy.gmail.com with SMTP id k1so40872nzf
        for <linux-mips@linux-mips.org>; Mon, 26 Sep 2005 00:06:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=H8rY23czP+pkeQsM5XXrHSpnbGI/07Z5dRjlmSrTZvUl73yQPUpCgBv51z803SNI0jlZJPpHXJY/4mwXqnzPyXLyRkLj1bu06Sc42vlsDX5ABiAA3eYO53NxotUJWAyqHf6iKvYQ4NNynvTvXY206TVygX7sCRgND2bv2sUpkGc=
Received: by 10.36.101.9 with SMTP id y9mr1497813nzb;
        Mon, 26 Sep 2005 00:06:50 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Mon, 26 Sep 2005 00:06:50 -0700 (PDT)
Message-ID: <cda58cb8050926000665f843dc@mail.gmail.com>
Date:	Mon, 26 Sep 2005 09:06:50 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	linux-mips@linux-mips.org
Subject: [PATCH] minor fix in asm-mips/module.h
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9037
X-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
Content-Length: 133
Lines: 6

This patch replaces an empty preprocessor condition #elif by #else. It
adds 4ksc and 4ksd as well.

Thanks.
--
               Franck

From vagabon.xyz@gmail.com Mon Sep 26 10:16:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 10:16:49 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.202]:61921 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S8133514AbVIZJQd convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 10:16:33 +0100
Received: by zproxy.gmail.com with SMTP id j2so160668nzf
        for <linux-mips@linux-mips.org>; Mon, 26 Sep 2005 02:16:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=eXFM4J32Zmu03HBl6Wpa1hEmkmOu0zjiX3Pa9fiBNEwEFO3HDiuv+Zd6oBzsZSNnL21BXxz3cxAxNVo1cg44x7iVOoeGg412s0AIcdPEbmPRrTHX75I0AbAi/Hu7FQU4st+KHXPufT/nj2lCSHS7aKFSqopvh8kB5UNUVUUiLxg=
Received: by 10.36.41.3 with SMTP id o3mr1286790nzo;
        Mon, 26 Sep 2005 02:16:27 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Mon, 26 Sep 2005 02:16:27 -0700 (PDT)
Message-ID: <cda58cb80509260216591eb96b@mail.gmail.com>
Date:	Mon, 26 Sep 2005 11:16:27 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	linux-mips@linux-mips.org
Subject: DISCONTIGMEM suuport on 32 bits MIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9038
X-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
Content-Length: 457
Lines: 14

Hi,

I'm working on a port of 32bit MIPS to a custom board with several
large holes in the memory map. I would like to know the status of
discontiguous memory on MIPS. I have noticed that ip27 Kconfig enables
this feature but I don't see any MIPS generic code that handles it...

Has anybody already done this ? If not then I'll try to work out what
needed from the corresponding i386 code, but I'd appreciate any
pointers.

Thanks
--
               Franck

From ralf@linux-mips.org Mon Sep 26 12:56:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 12:56:21 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:12062 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S8133525AbVIZL4C (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 12:56:02 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8QBteSp006251;
	Mon, 26 Sep 2005 13:55:40 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8QBtdbr006250;
	Mon, 26 Sep 2005 13:55:39 +0200
Date:	Mon, 26 Sep 2005 13:55:39 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Message-ID: <20050926115539.GB3175@linux-mips.org>
References: <cda58cb8050926000665f843dc@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb8050926000665f843dc@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9039
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 205
Lines: 8

On Mon, Sep 26, 2005 at 09:06:50AM +0200, Franck wrote:

> This patch replaces an empty preprocessor condition #elif by #else. It
> adds 4ksc and 4ksd as well.

You forgot to include the patch ...

  Ralf

From vagabon.xyz@gmail.com Mon Sep 26 13:05:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 13:06:05 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.202]:24262 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S8133525AbVIZMFo (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Mon, 26 Sep 2005 13:05:44 +0100
Received: by zproxy.gmail.com with SMTP id j2so193329nzf
        for <linux-mips@linux-mips.org>; Mon, 26 Sep 2005 05:05:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=AihEOyNcP+aGufApcrJNKVZLv4/ALYyTymmlJxNcJoQyDlZEvu92aDlHYCyGaxZJpRvyrotPTNP8c2YCU6XCGZA9PdSfP+t22U1IBchJe3x8AeGxrirTd3fqDuFQyby2djPHRURi9jE6WOrEEMUn4wTOMmQ92ysPQvjnBNuoUjk=
Received: by 10.36.33.15 with SMTP id g15mr1527660nzg;
        Mon, 26 Sep 2005 05:05:36 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Mon, 26 Sep 2005 05:05:36 -0700 (PDT)
Message-ID: <cda58cb805092605057f7cad7d@mail.gmail.com>
Date:	Mon, 26 Sep 2005 14:05:36 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050926115539.GB3175@linux-mips.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_3490_19956359.1127736336430"
References: <cda58cb8050926000665f843dc@mail.gmail.com>
	 <20050926115539.GB3175@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9040
X-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
Content-Length: 1367
Lines: 34

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

2005/9/26, Ralf Baechle <ralf@linux-mips.org>:
> On Mon, Sep 26, 2005 at 09:06:50AM +0200, Franck wrote:
>
> > This patch replaces an empty preprocessor condition #elif by #else. It
> > adds 4ksc and 4ksd as well.
>
> You forgot to include the patch ...

sorry for that, here it is...

Thanks
--
               Franck

------=_Part_3490_19956359.1127736336430
Content-Type: text/x-patch; name="module.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="module.patch"

LS0tIG1vZHVsZS5ofm9sZAkyMDA1LTA5LTI2IDE0OjAyOjMyLjAwMDAwMDAwMCArMDIwMAorKysg
bW9kdWxlLmgJMjAwNS0wOS0yNiAwOTo1NDowOC4wMDAwMDAwMDAgKzAyMDAKQEAgLTExMyw3ICsx
MTMsMTEgQEAgc2VhcmNoX21vZHVsZV9kYmV0YWJsZXModW5zaWduZWQgbG9uZyBhZAogI2RlZmlu
ZSBNT0RVTEVfUFJPQ19GQU1JTFkgIlJNOTAwMCIKICNlbGlmIGRlZmluZWQgQ09ORklHX0NQVV9T
QjEKICNkZWZpbmUgTU9EVUxFX1BST0NfRkFNSUxZICJTQjEiCi0jZWxpZgorI2VsaWYgZGVmaW5l
ZCBDT05GSUdfQ1BVXzRLU0MKKyNkZWZpbmUgTU9EVUxFX1BST0NfRkFNSUxZICI0S1NDIgorI2Vs
aWYgZGVmaW5lZCBDT05GSUdfQ1BVXzRLU0QKKyNkZWZpbmUgTU9EVUxFX1BST0NfRkFNSUxZICI0
S1NEIgorI2Vsc2UKICNlcnJvciBNT0RVTEVfUFJPQ19GQU1JTFkgdW5kZWZpbmVkIGZvciB5b3Vy
IHByb2Nlc3NvciBjb25maWd1cmF0aW9uCiAjZW5kaWYKIAo=
------=_Part_3490_19956359.1127736336430--

From ralf@linux-mips.org Mon Sep 26 13:21:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 13:21:38 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:516 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S8133525AbVIZMVX (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 13:21:23 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8QCLEbP007128;
	Mon, 26 Sep 2005 14:21:14 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8QCLEAk007127;
	Mon, 26 Sep 2005 14:21:14 +0200
Date:	Mon, 26 Sep 2005 14:21:14 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Message-ID: <20050926122114.GC3175@linux-mips.org>
References: <cda58cb80509260216591eb96b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb80509260216591eb96b@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9041
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 839
Lines: 20

On Mon, Sep 26, 2005 at 11:16:27AM +0200, Franck wrote:

> I'm working on a port of 32bit MIPS to a custom board with several
> large holes in the memory map. I would like to know the status of
> discontiguous memory on MIPS. I have noticed that ip27 Kconfig enables
> this feature but I don't see any MIPS generic code that handles it...

IP27 currently the only system that absolutely needs discontiguous
memory in order to work at all.  A few other systems could make use of
discontiguous memory to reduce the waste of memory - the family of
Broadcom SB1 based systems comes to mind.

> Has anybody already done this ? If not then I'll try to work out what
> needed from the corresponding i386 code, but I'd appreciate any
> pointers.

See IP27.  IP27 has one added extra complexity, it's a NUMA system but
you can ignore that.

  Ralf

From vagabon.xyz@gmail.com Mon Sep 26 13:46:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 13:46:30 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.193]:64437 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S8133532AbVIZMqM convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 13:46:12 +0100
Received: by zproxy.gmail.com with SMTP id j2so202565nzf
        for <linux-mips@linux-mips.org>; Mon, 26 Sep 2005 05:46:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mfMWmvTlVaHRIq70DnN3y06dOfb133pm8M6zxNQmyZ08MS1v72AXhoqZeohxXp2RFSbqN7jj/puzGlx1P/a5zDsIPMhh3yOfoosJW9bsA+I/qTQBdofallIChUY6VZOzh1o5pSh9/pYd9ulgy4hdwsYDn1lpL/AEc/UxWjUKGCI=
Received: by 10.36.41.3 with SMTP id o3mr1424344nzo;
        Mon, 26 Sep 2005 05:46:02 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Mon, 26 Sep 2005 05:46:02 -0700 (PDT)
Message-ID: <cda58cb80509260546a6f4118@mail.gmail.com>
Date:	Mon, 26 Sep 2005 14:46:02 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050926122114.GC3175@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <cda58cb80509260216591eb96b@mail.gmail.com>
	 <20050926122114.GC3175@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9042
X-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
Content-Length: 992
Lines: 25

Hi Ralf,

2005/9/26, Ralf Baechle <ralf@linux-mips.org>:
> On Mon, Sep 26, 2005 at 11:16:27AM +0200, Franck wrote:
>
> > I'm working on a port of 32bit MIPS to a custom board with several
> > large holes in the memory map. I would like to know the status of
> > discontiguous memory on MIPS. I have noticed that ip27 Kconfig enables
> > this feature but I don't see any MIPS generic code that handles it...
>
> IP27 currently the only system that absolutely needs discontiguous
> memory in order to work at all.  A few other systems could make use of
> discontiguous memory to reduce the waste of memory - the family of
> Broadcom SB1 based systems comes to mind.
>

Isn't discontiguous memory common for embedded system as well ? I
thought so...Anyways can we make discontiguous memory thing move into
generic MIPS code so every future needs for that will profit ? I
looked at other arch, and they seem to implement it that way (in
arch/xxx/mm/discontig.c).

Thanks
--
               Franck

From maillist@jg555.com Mon Sep 26 16:18:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Sep 2005 16:18:36 +0100 (BST)
Received: from 64-30-195-78.dsl.linkline.com ([64.30.195.78]:33720 "EHLO
	jg555.com") by ftp.linux-mips.org with ESMTP id S8133514AbVIZPSR convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Mon, 26 Sep 2005 16:18:17 +0100
Received: from [172.16.0.55] ([::ffff:172.16.0.55])
  (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by jg555.com with esmtp; Mon, 26 Sep 2005 08:18:14 -0700
  id 00008476.43381136.00004C1D
Message-ID: <4338111C.6040401@jg555.com>
Date:	Mon, 26 Sep 2005 08:17:48 -0700
From:	Jim Gifford <maillist@jg555.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Daniel Jacobowitz <dan@debian.org>
CC:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: MIPS64 NPTL Status
References: <43323D35.9030905@jg555.com> <20050922213020.GA15905@nevyn.them.org> <43333001.3080703@jg555.com>
In-Reply-To: <43333001.3080703@jg555.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Return-Path: <maillist@jg555.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9043
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maillist@jg555.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2932
Lines: 42

Daniel,
    Got passed the first issue, but the second one came around when 
trying to get NPTL to compile with N32. Here's what I got. The code does 
compile under pure 64 bit no problems.

mips64el-unknown-linux-gnu-gcc -mel -march=r5000 -mtune=r5000 -mabi=n32 ../sysdeps/unix/sysv/linux/ptrace.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g      -I../include -I. -I/mnt/lfs-mips64/build/glibc-cross-n32/misc -I.. -I../libio -I../nptl -I/mnt/lfs-mips64/build/glibc-cross-n32 -I../sysdeps/mips/elf -I../libidn/sysdeps/unix -I../nptl/sysdeps/unix/sysv/linux/mips/mips64 -I../nptl/sysdeps/unix/sysv/linux/mips -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/mips -I../nptl/sysdeps/generic -I../sysdeps/unix/sysv/linux/mips/mips64/n32 -I../sysdeps/unix/sysv/linux/mips/mips64 -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips/mips64/n32 -I../sysdeps/unix/mips/mips64 -I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mips64/n32 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/mips/mips64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/mips -I../sysdeps/wordsize-32 -I../sysdeps/mips/fpu -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /home/lfs-mips64/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.0.1/include -isystem /tools/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC     -o /mnt/lfs-mips64/build/glibc-cross-n32/misc/ptrace.o -MD -MP -MF /mnt/lfs-mips64/build/glibc-cross-n32/misc/ptrace.o.dt -MT /mnt/lfs-mips64/build/glibc-cross-n32/misc/ptrace.o
../sysdeps/unix/sysv/linux/ptrace.c:31: error: conflicting types for 'ptrace'
../sysdeps/unix/sysv/linux/mips/sys/ptrace.h:129: error: previous declaration of 'ptrace' was here
../sysdeps/unix/sysv/linux/ptrace.c: In function 'ptrace':
../sysdeps/unix/sysv/linux/ptrace.c:104: warning: cast from pointer to integer of different size
../sysdeps/unix/sysv/linux/ptrace.c:104: warning: cast from pointer to integer of different size
make[2]: *** [/mnt/lfs-mips64/build/glibc-cross-n32/misc/ptrace.o] Error 1
make[2]: Leaving directory `/mnt/lfs-mips64/build/glibc-20050919/misc'
make[1]: *** [misc/subdir_lib] Error 2
make[1]: Leaving directory `/mnt/lfs-mips64/build/glibc-20050919'
make: *** [all] Error 2


Line 127 - ptrace.h
#if _MIPS_SIM == _ABIN32
__extension__ extern long long int ptrace
  (enum __ptrace_request __request, ...) __THROW;
#else
extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
#endif

Line 31 - ptrace.c

long int
ptrace (enum __ptrace_request request, ...)
{
  long int res, ret;




-- 
----
Jim Gifford
maillist@jg555.com



From florian.delizy@sagem.com Tue Sep 27 08:52:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 08:52:34 +0100 (BST)
Received: from ns1.sagem.com ([62.160.59.65]:6269 "EHLO mx1.sagem.com")
	by ftp.linux-mips.org with ESMTP id S8133568AbVI0HwT (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 08:52:19 +0100
To:	linux-mips@linux-mips.org
Subject: linux-mips Vs kernel.org
MIME-Version: 1.0
Message-ID: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
From:	Florian DELIZY <florian.delizy@sagem.com>
Date:	Tue, 27 Sep 2005 09:52:01 +0200
Content-Type: multipart/alternative; boundary="=_alternative 002B3D8CC1257089_="
Return-Path: <florian.delizy@sagem.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9044
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: florian.delizy@sagem.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1196
Lines: 30

Message en plusieurs parties au format MIME
--=_alternative 002B3D8CC1257089_=
Content-Type: text/plain; charset="us-ascii"

Hello,

We currently working with the 2.6.12 kernel, and wondering which from 
linux-mips or kernel.org version we should use,
in a more general manner, what are the differences between linux-mips and 
kernel.org kernel source code, is one the
mirror of the other, or is there one that frequently merge with the other 
?

Regards

Florian Delizy
--=_alternative 002B3D8CC1257089_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">We currently working with the 2.6.12 kernel, and wondering which from linux-mips or kernel.org version we should use,</font>
<br><font size=2 face="sans-serif">in a more general manner, what are the differences between linux-mips and kernel.org kernel source code, is one the</font>
<br><font size=2 face="sans-serif">mirror of the other, or is there one that frequently merge with the other ?</font>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br>
<br><font size=2 face="sans-serif">Florian Delizy</font>
--=_alternative 002B3D8CC1257089_=--

From jbglaw@lug-owl.de Tue Sep 27 09:12:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 09:12:55 +0100 (BST)
Received: from lug-owl.de ([195.71.106.12]:41168 "EHLO lug-owl.de")
	by ftp.linux-mips.org with ESMTP id S8133564AbVI0IMh (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 09:12:37 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id C5415F0056; Tue, 27 Sep 2005 10:12:31 +0200 (CEST)
Date:	Tue, 27 Sep 2005 10:12:31 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: linux-mips Vs kernel.org
Message-ID: <20050927081231.GZ5743@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="T0u6oYl84yPn00Od"
Content-Disposition: inline
In-Reply-To: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9045
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1669
Lines: 52


--T0u6oYl84yPn00Od
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-09-27 09:52:01 +0200, Florian DELIZY <florian.delizy@sagem.com=
> wrote:
> We currently working with the 2.6.12 kernel, and wondering which from=20
> linux-mips or kernel.org version we should use,
> in a more general manner, what are the differences between linux-mips and=
=20
> kernel.org kernel source code, is one the
> mirror of the other, or is there one that frequently merge with the other=
=20

Use the linux-mips.org tree to do any work.

To find out about the differences, just download a kernel.org kernel
and run a 'diff -Nurp' against what you find on linux-mips.org.

Up to now, merges happened every now-and-then, but not on a very
regular basis. However, there's hope for more timely merges since Ralf
is on the way to move the souce base over to GIT, which should ease
further merges...

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--T0u6oYl84yPn00Od
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDOP7vHb1edYOZ4bsRAmptAJ0bHFKfzgNHqfbb8pKuHavPO9dSUACfS/3r
ilrlLndROTxvCpEP2/2h95A=
=2MzK
-----END PGP SIGNATURE-----

--T0u6oYl84yPn00Od--

From matej.kupljen@ultra.si Tue Sep 27 09:17:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 09:18:18 +0100 (BST)
Received: from deliver-1.mx.triera.net ([213.161.0.31]:15261 "HELO
	deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP
	id S8133564AbVI0IR7 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 09:17:59 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 4356EC05D
	for <linux-mips@linux-mips.org>; Tue, 27 Sep 2005 10:17:44 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id 5EDCC1BC085
	for <linux-mips@linux-mips.org>; Tue, 27 Sep 2005 10:17:45 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 2B3011A18C6
	for <linux-mips@linux-mips.org>; Tue, 27 Sep 2005 10:17:46 +0200 (CEST)
Subject: Floating point performance
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	linux-mips@linux-mips.org
Content-Type: text/plain
Date:	Tue, 27 Sep 2005 10:17:07 +0200
Message-Id: <1127809027.26702.14.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9046
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 1694
Lines: 44

Hi

I've built soft float toolchain (with crosstool) and then build
MPlayer with it. The performance is very low. I cannot even
play the mp3 file with MPlayer on DBAU1200 with 400MHz CPU!

I used
GCC: 3.3.5
GLIBC: 2.3.5
BINUTILS: 2.16.1

I did some profiling and this is what I get:
-----------------------------------------------------------------------------------
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 18.09     44.70    44.70                             __pack_f
 17.30     87.44    42.74                             _fpadd_parts
 15.82    126.54    39.10                             __mulsf3
 15.28    164.31    37.77                             __unpack_f
  6.49    180.36    16.05                             _fpadd_parts
  5.30    193.45    13.09    17424     0.00     0.00  dct64_1
  4.75    205.18    11.73                             __subsf3
  4.04    215.16     9.98                             __addsf3
  3.68    224.26     9.10    17424     0.00     0.00  synth_1to1
  1.90    228.96     4.70                             __pack_d
  1.20    231.92     2.96                             __unpack_d
  1.17    234.80     2.88                             __muldf3
-----------------------------------------------------------------------------------

As it seems, all the time is spent in the FP routines. 
I decided to use SF toolchain, because they should be faster
then FPU emulator (at least it is on ARM), but did no test
this with emulator.

Does anybody use MPlayer on MIPS? 
What performance do you get?
Any other suggestions?

BR,
Matej


From jerry@wicomtechnologies.com Tue Sep 27 09:42:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 09:44:21 +0100 (BST)
Received: from smtp.wicomtechnologies.com ([195.234.214.162]:54502 "EHLO
	smtp.wicomtechnologies.com") by ftp.linux-mips.org with ESMTP
	id S8133568AbVI0Im0 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 09:42:26 +0100
Received: from [192.168.0.24] (wcm-24.wicom.kiev.ua [192.168.0.24] (may be forged))
	by smtp.wicomtechnologies.com (8.12.10/8.12.10) with ESMTP id j8R8g7Xp091099;
	Tue, 27 Sep 2005 11:42:07 +0300 (EEST)
	(envelope-from jerry@wicomtechnologies.com)
Date:	Tue, 27 Sep 2005 11:42:08 +0300
From:	Jerry <jerry@wicomtechnologies.com>
X-Mailer: The Bat! (v3.51.10) Professional
Reply-To: Jerry <jerry@wicomtechnologies.com>
X-Priority: 3 (Normal)
Message-ID: <77412291.20050927114208@wicomtechnologies.com>
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	linux-mips@linux-mips.org
Subject: Re: Floating point performance
In-Reply-To: <1127809027.26702.14.camel@localhost.localdomain>
References: <1127809027.26702.14.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jerry@wicomtechnologies.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9047
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jerry@wicomtechnologies.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1048
Lines: 28

>[In reply to "Floating point performance" from Matej Kupljen <matej.kupljen@ultra.si> to linux-mips@linux-mips.org <linux-mips@linux-mips.org>  27.09.2005 11:17]

> Hi

> I've built soft float toolchain (with crosstool) and then build
> MPlayer with it. The performance is very low. I cannot even
> As it seems, all the time is spent in the FP routines.
> I decided to use SF toolchain, because they should be faster
> then FPU emulator (at least it is on ARM), but did no test
> this with emulator.

Decoding of mp3 (and/or other media) with FP routines is extremely
slow on systems w/o fp processor. No matter is it "soft-float" or
"kernel-trap emulator". Both cases it is the emulator.(but SF is a
litthe faster because it has no "trap" overhead).

> Does anybody use MPlayer on MIPS? 
> What performance do you get?

I used mplayed with libmad (libmad uses only integer ops to decode
mp3). It consumes about 10-15% of cpu time (au1200) to play mp3 file.



   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.51.10>- -<27.09.2005 11:33>-
  (") (")


From florian.delizy@sagem.com Tue Sep 27 10:06:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 10:06:50 +0100 (BST)
Received: from ns2.sagem.com ([62.160.59.241]:35188 "EHLO mx2.sagem.com")
	by ftp.linux-mips.org with ESMTP id S8133566AbVI0JGd (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 10:06:33 +0100
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc:	linux-mips@linux-mips.org
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_linux-mips_Vs_kernel=2Eorg?=
MIME-Version: 1.0
Message-ID: <OF09624E56.0EE9A8E5-ONC1257089.0031D0AF-C1257089.00320CF1@sagem.com>
From:	Florian DELIZY <florian.delizy@sagem.com>
Date:	Tue, 27 Sep 2005 11:06:25 +0200
Content-Type: multipart/mixed; boundary="=_mixed 00320CF0C1257089_="
Return-Path: <florian.delizy@sagem.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9048
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: florian.delizy@sagem.com
Precedence: bulk
X-list: linux-mips
Content-Length: 5321
Lines: 150

--=_mixed 00320CF0C1257089_=
Content-Type: multipart/alternative; boundary="=_alternative 00320CF0C1257089_="


--=_alternative 00320CF0C1257089_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is that meaning that kernel.org source code is merged into linux-mips.org=20
repository,=20
or that linux-mips.org code is merged into the kernel.org source=20
repository ?






Jan-Benedict Glaw <jbglaw@lug-owl.de>

Envoy=E9 par : linux-mips-bounce@linux-mips.org
27/09/2005 10:12
Remis le : 27/09/2005 10:13

=20
        Pour :  linux-mips@linux-mips.org
        cc :    (ccc : Florian DELIZY/EXT/SAGEM)
        Objet : Re: linux-mips Vs kernel.org



On Tue, 2005-09-27 09:52:01 +0200, Florian DELIZY=20
<florian.delizy@sagem.com> wrote:
> We currently working with the 2.6.12 kernel, and wondering which from
> linux-mips or kernel.org version we should use,
> in a more general manner, what are the differences between linux-mips=20
and
> kernel.org kernel source code, is one the
> mirror of the other, or is there one that frequently merge with the=20
other

Use the linux-mips.org tree to do any work.

To find out about the differences, just download a kernel.org kernel
and run a 'diff -Nurp' against what you find on linux-mips.org.

Up to now, merges happened every now-and-then, but not on a very
regular basis. However, there's hope for more timely merges since Ralf
is on the way to move the souce base over to GIT, which should ease
further merges...

MfG, JBG

--
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481 =5F O =5F
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg=20
=5F =5F O
f=FCr einen Freien Staat voll Freier B=FCrger"  | im Internet! |   im Irak!=
 O=20
O O
ret =3D do=5Factions((curr | FREE=5FSPEECH) & ~(NEW=5FCOPYRIGHT=5FLAW | DRM=
 |=20
TCPA));



--=_alternative 00320CF0C1257089_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">Is that meaning that kernel.org sour=
ce code is merged into linux-mips.org repository, </font>
<br><font size=3D2 face=3D"sans-serif">or that linux-mips.org code is merge=
d into the kernel.org source repository ?</font>
<br>
<br>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>Jan-Benedict Glaw &lt;jbglaw@lug-=
owl.de&gt;</b></font>
<br>
<br><font size=3D1 face=3D"sans-serif">Envoy=E9 par : linux-mips-bounce@lin=
ux-mips.org</font>
<p><font size=3D1 face=3D"sans-serif">27/09/2005 10:12</font>
<br><font size=3D1 face=3D"sans-serif">Remis le : 27/09/2005 10:13</font>
<br>
<td><font size=3D1 face=3D"Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Pour : &=
nbsp; &nbsp; &nbsp; &nbsp;linux-mips@linux-mips.org</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc : &nb=
sp; &nbsp; &nbsp; &nbsp;(ccc : Florian DELIZY/EXT/SAGEM)</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Objet : =
&nbsp; &nbsp; &nbsp; &nbsp;Re: linux-mips Vs kernel.org</font>
<br></table>
<br>
<br>
<br><font size=3D2><tt>On Tue, 2005-09-27 09:52:01 +0200, Florian DELIZY &l=
t;florian.delizy@sagem.com&gt; wrote:<br>
&gt; We currently working with the 2.6.12 kernel, and wondering which from<=
br>
&gt; linux-mips or kernel.org version we should use,<br>
&gt; in a more general manner, what are the differences between linux-mips =
and<br>
&gt; kernel.org kernel source code, is one the<br>
&gt; mirror of the other, or is there one that frequently merge with the ot=
her<br>
</tt></font>
<br><font size=3D2><tt>Use the linux-mips.org tree to do any work.<br>
</tt></font>
<br><font size=3D2><tt>To find out about the differences, just download a k=
ernel.org kernel<br>
and run a 'diff -Nurp' against what you find on linux-mips.org.<br>
</tt></font>
<br><font size=3D2><tt>Up to now, merges happened every now-and-then, but n=
ot on a very<br>
regular basis. However, there's hope for more timely merges since Ralf<br>
is on the way to move the souce base over to GIT, which should ease<br>
further merges...<br>
</tt></font>
<br><font size=3D2><tt>MfG, JBG<br>
</tt></font>
<br><font size=3D2><tt>--<br>
Jan-Benedict Glaw &nbsp; &nbsp; &nbsp; jbglaw@lug-owl.de &nbsp; &nbsp;. +49=
-172-7608481 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =5F O =5F<br>
&quot;Eine Freie Meinung in &nbsp;einem Freien Kopf &nbsp; &nbsp;| Gegen Ze=
nsur | Gegen Krieg &nbsp;=5F =5F O</tt></font>
<br><font size=3D2><tt>f=FCr einen Freien Staat voll Freier B=FCrger&quot; =
&nbsp;| im Internet! | &nbsp; im Irak! &nbsp; O O O<br>
ret =3D do=5Factions((curr | FREE=5FSPEECH) &amp; ~(NEW=5FCOPYRIGHT=5FLAW |=
 DRM | TCPA));</tt></font>
<br>
<br>
<br>
--=_alternative 00320CF0C1257089_=--
--=_mixed 00320CF0C1257089_=
Content-Type: application/octet-stream; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"
Content-Transfer-Encoding: base64

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMSAoR05V
L0xpbnV4KQ0KDQppRDhEQlFGRE9QN3ZIYjFlZFlPWjRic1JBbXB0QUowYkhGS2Z6Z05IcWZiYjhw
S3VIYXZQTzlkU1VBQ2ZTLzNyDQppbHJsTG5kUk9UeHZDcEVQMi8yaDk1QT0NCj0yTXpLDQotLS0t
LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K

--=_mixed 00320CF0C1257089_=--

From jbglaw@lug-owl.de Tue Sep 27 10:12:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 10:12:15 +0100 (BST)
Received: from lug-owl.de ([195.71.106.12]:28122 "EHLO lug-owl.de")
	by ftp.linux-mips.org with ESMTP id S8133566AbVI0JMA (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 10:12:00 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 099E7F0054; Tue, 27 Sep 2005 11:12:00 +0200 (CEST)
Date:	Tue, 27 Sep 2005 11:11:59 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: =?utf-8?Q?R=C3=A9f?=
	=?utf-8?Q?=2E?= : Re: linux-mips Vs kernel.org
Message-ID: <20050927091159.GB5743@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <OF09624E56.0EE9A8E5-ONC1257089.0031D0AF-C1257089.00320CF1@sagem.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jPJw4wSVUvI9Tm/b"
Content-Disposition: inline
In-Reply-To: <OF09624E56.0EE9A8E5-ONC1257089.0031D0AF-C1257089.00320CF1@sagem.com>
X-Operating-System: Linux mail 2.6.12.3lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9049
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1162
Lines: 45


--jPJw4wSVUvI9Tm/b
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-09-27 11:06:25 +0200, Florian DELIZY <florian.delizy@sagem.com=
> wrote:
> Is that meaning that kernel.org source code is merged into linux-mips.org=
=20
> repository,=20

Yes. Regularly.

> or that linux-mips.org code is merged into the kernel.org source=20
> repository ?

Yes. From time to time.

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 f=C3=BCr einen Freien Staat voll Freier B=C3=BCrger"  | im Internet! |   i=
m Irak!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--jPJw4wSVUvI9Tm/b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDOQzfHb1edYOZ4bsRAtFwAJ0VQHTUWDQP+iAAFFy26Sp+8r+WoQCgh5Ti
WI5hXtbGMlYF7tBQ3Ov8B6k=
=i9RF
-----END PGP SIGNATURE-----

--jPJw4wSVUvI9Tm/b--

From kevink@mips.com Tue Sep 27 10:12:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 10:13:19 +0100 (BST)
Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:31407 "EHLO
	dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133566AbVI0JM7
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 10:12:59 +0100
Received: from mercury.mips.com (sbcns-dmz [209.232.97.193])
	by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j8R9CnCq018784;
	Tue, 27 Sep 2005 02:12:50 -0700 (PDT)
Received: from [192.168.236.16] (grendel [192.168.236.16])
	by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j8R9Cl17007723;
	Tue, 27 Sep 2005 02:12:47 -0700 (PDT)
Message-ID: <43390E6E.7030703@mips.com>
Date:	Tue, 27 Sep 2005 11:18:38 +0200
From:	"Kevin D. Kissell" <kevink@mips.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Florian DELIZY <florian.delizy@sagem.com>
CC:	Jan-Benedict Glaw <jbglaw@lug-owl.de>, linux-mips@linux-mips.org
Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_linux-mips_Vs_ke?=
 =?ISO-8859-1?Q?rnel=2Eorg?=
References: <OF09624E56.0EE9A8E5-ONC1257089.0031D0AF-C1257089.00320CF1@sagem.com>
In-Reply-To: <OF09624E56.0EE9A8E5-ONC1257089.0031D0AF-C1257089.00320CF1@sagem.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.39
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9050
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 289
Lines: 11

Florian DELIZY wrote:
> Is that meaning that kernel.org source code is merged into linux-mips.org 
> repository, 
> or that linux-mips.org code is merged into the kernel.org source 
> repository ?

Les deux. But kernel.org -> linux-mips.org merges are more frequent.

	Regards,

	Kevin K.

From ralf@linux-mips.org Tue Sep 27 10:39:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 10:39:47 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:48908 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S8133567AbVI0Jj2 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 10:39:28 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8R9dMND004087;
	Tue, 27 Sep 2005 11:39:22 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8R9dMVi004086;
	Tue, 27 Sep 2005 11:39:22 +0200
Date:	Tue, 27 Sep 2005 11:39:22 +0200
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Florian DELIZY <florian.delizy@sagem.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: linux-mips Vs kernel.org
Message-ID: <20050927093922.GA3793@linux-mips.org>
References: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9051
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 617
Lines: 16

On Tue, Sep 27, 2005 at 09:52:01AM +0200, Florian DELIZY wrote:

> We currently working with the 2.6.12 kernel, and wondering which from 
> linux-mips or kernel.org version we should use,
> in a more general manner, what are the differences between linux-mips and 
> kernel.org kernel source code, is one the
> mirror of the other, or is there one that frequently merge with the other 
> ?

At this stage the kernel.org tree is quite unusable for MIPS.

As others have already said, I'm about to dump CVS from linux-mips.org.
You can still access the CVS archive, just don't expect any updates to
it anymore.

  Ralf

From drow@nevyn.them.org Tue Sep 27 14:09:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 14:10:18 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:20440 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8134019AbVI0NJy (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 14:09:54 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EKFDT-0000EI-T4; Tue, 27 Sep 2005 09:09:51 -0400
Date:	Tue, 27 Sep 2005 09:09:51 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Jim Gifford <maillist@jg555.com>
Cc:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: MIPS64 NPTL Status
Message-ID: <20050927130951.GA867@nevyn.them.org>
References: <43323D35.9030905@jg555.com> <20050922213020.GA15905@nevyn.them.org> <43333001.3080703@jg555.com> <4338111C.6040401@jg555.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4338111C.6040401@jg555.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9052
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 412
Lines: 13

On Mon, Sep 26, 2005 at 08:17:48AM -0700, Jim Gifford wrote:
> Daniel,
>    Got passed the first issue, but the second one came around when 
> trying to get NPTL to compile with N32. Here's what I got. The code does 
> compile under pure 64 bit no problems.

I must have sent you an outdated patch.  Remove the mips-specific
sys/ptrace.h header and use the generic one.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

From yuasa@hh.iij4u.or.jp Tue Sep 27 16:54:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 16:54:56 +0100 (BST)
Received: from mo00.iij4u.or.jp ([210.130.0.19]:246 "EHLO mo00.iij4u.or.jp")
	by ftp.linux-mips.org with ESMTP id S8134227AbVI0Pyk (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 16:54:40 +0100
Received: MO(mo00) for <linux-mips@linux-mips.org> id j8RFsYxW019230; Wed, 28 Sep 2005 00:54:34 +0900 (JST)
Received: MDO(mdo00) id j8RFsX3T018902; Wed, 28 Sep 2005 00:54:33 +0900 (JST)
Received: from stratos (h195.p501.iij4u.or.jp [210.149.245.195])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j8RFsWT6002806
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT)
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 00:54:33 +0900 (JST)
Date:	Wed, 28 Sep 2005 00:54:32 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	linux-mips@linux-mips.org
Subject: Re: linux-mips Vs kernel.org
Message-Id: <20050928005432.7d45b2f9.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20050927093922.GA3793@linux-mips.org>
References: <OFDDFCB8DC.1BFCCB3E-ONC1257089.002AE830-C1257089.002B3D8D@sagem.com>
	<20050927093922.GA3793@linux-mips.org>
X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9053
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 611
Lines: 19

Hi,

On Tue, 27 Sep 2005 11:39:22 +0200
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Tue, Sep 27, 2005 at 09:52:01AM +0200, Florian DELIZY wrote:
> 
> > We currently working with the 2.6.12 kernel, and wondering which from 
> > linux-mips or kernel.org version we should use,
> > in a more general manner, what are the differences between linux-mips and 
> > kernel.org kernel source code, is one the
> > mirror of the other, or is there one that frequently merge with the other 
> > ?
> 
> At this stage the kernel.org tree is quite unusable for MIPS.

I have no problem kernel.org GIT with VR41xx.

Yoichi

From oski2001@hotmail.com Tue Sep 27 18:21:32 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 18:21:48 +0100 (BST)
Received: from bay101-dav7.bay101.hotmail.com ([64.4.56.79]:47440 "EHLO
	hotmail.com") by ftp.linux-mips.org with ESMTP id S8133750AbVI0RVc
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 18:21:32 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 27 Sep 2005 10:18:16 -0700
Message-ID: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
Received: from 81.159.219.80 by BAY101-DAV7.phx.gbl with DAV;
	Tue, 27 Sep 2005 17:18:16 +0000
X-Originating-IP: [81.159.219.80]
X-Originating-Email: [oski2001@hotmail.com]
X-Sender: oski2001@hotmail.com
From:	"oski" <oski2001@hotmail.com>
To:	<linux-mips@linux-mips.org>
Subject: Compiling a kernel for ibm z50
Date:	Tue, 27 Sep 2005 18:19:51 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-OriginalArrivalTime: 27 Sep 2005 17:18:16.0668 (UTC) FILETIME=[72F669C0:01C5C387]
Return-Path: <oski2001@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9054
X-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
Content-Length: 712
Lines: 24



Hi,

I am a newbie trying to compile a kernel for my z50 and up to now failed.

This is my set up:
-An old Pentium II box with Redhat 8
-Downloaded linux-2.6.13.mipscvs-20050904 from www.longlandclan...and bzip2
and tar into /usr/src.
-Installed the mipsel crosscompiler from MIPS SDE
-After make config, when trying to make dep, I get a warning: make dep is
unnecessary now.
-Doing a ls arch/mips/boot I get a file called "compressed" with only a
folder called "CVS" .
 Questions:
1.Can somebody tell me what I am doing wrong?
2.Give me some advise on the proper way to crosscompile?
3.Has somebody a compiled kernel (and root) that will be willing to share
with me, to boot using hpcboot?

Many thanks

oski

From geert@linux-m68k.org Tue Sep 27 19:42:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 19:43:13 +0100 (BST)
Received: from witte.sonytel.be ([80.88.33.193]:39887 "EHLO witte.sonytel.be")
	by ftp.linux-mips.org with ESMTP id S8134318AbVI0Smx (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 19:42:53 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j8RId2va021796;
	Tue, 27 Sep 2005 20:39:02 +0200 (MEST)
Date:	Tue, 27 Sep 2005 20:39:00 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	oski <oski2001@hotmail.com>
cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Compiling a kernel for ibm z50
In-Reply-To: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
Message-ID: <Pine.LNX.4.62.0509272037590.30305@numbat.sonytel.be>
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9055
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 701
Lines: 21

On Tue, 27 Sep 2005, oski wrote:
> I am a newbie trying to compile a kernel for my z50 and up to now failed.
> 
> This is my set up:
> -An old Pentium II box with Redhat 8
> -Downloaded linux-2.6.13.mipscvs-20050904 from www.longlandclan...and bzip2
> and tar into /usr/src.
> -Installed the mipsel crosscompiler from MIPS SDE

This is a FAQ, please use a real mipsel-linux crosscompiler instead.

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 oski2001@hotmail.com Tue Sep 27 20:06:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 20:06:54 +0100 (BST)
Received: from bay101-dav7.bay101.hotmail.com ([64.4.56.79]:51377 "EHLO
	hotmail.com") by ftp.linux-mips.org with ESMTP id S8134343AbVI0TGa
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Sep 2005 20:06:30 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 27 Sep 2005 12:04:41 -0700
Message-ID: <BAY101-DAV78DFA4E9067D7C54B9527D28A0@phx.gbl>
Received: from 81.159.219.80 by BAY101-DAV7.phx.gbl with DAV;
	Tue, 27 Sep 2005 19:04:40 +0000
X-Originating-IP: [81.159.219.80]
X-Originating-Email: [oski2001@hotmail.com]
X-Sender: oski2001@hotmail.com
From:	"oski" <oski2001@hotmail.com>
To:	"Geert Uytterhoeven" <geert@linux-m68k.org>
Cc:	<linux-mips@linux-mips.org>
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl> <Pine.LNX.4.62.0509272037590.30305@numbat.sonytel.be>
Subject: Re: Compiling a kernel for ibm z50
Date:	Tue, 27 Sep 2005 20:06:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-OriginalArrivalTime: 27 Sep 2005 19:04:41.0098 (UTC) FILETIME=[50611EA0:01C5C396]
Return-Path: <oski2001@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9056
X-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
Content-Length: 1222
Lines: 43

Hi,
In fact I changed to the mipsel SDE because I had the same results after
using mipsel-linux-binutils-2.14-3.i386.rpm and
mipsel-linux-gcc-2.95.3-23.i386.rpm.
Could be related to the kernel source I used?
thanks for answering.

oski
----- Original Message ----- 
From: "Geert Uytterhoeven" <geert@linux-m68k.org>
To: "oski" <oski2001@hotmail.com>
Cc: "Linux/MIPS Development" <linux-mips@linux-mips.org>
Sent: Tuesday, September 27, 2005 7:39 PM
Subject: Re: Compiling a kernel for ibm z50


> On Tue, 27 Sep 2005, oski wrote:
> > I am a newbie trying to compile a kernel for my z50 and up to now
failed.
> >
> > This is my set up:
> > -An old Pentium II box with Redhat 8
> > -Downloaded linux-2.6.13.mipscvs-20050904 from www.longlandclan...and
bzip2
> > and tar into /usr/src.
> > -Installed the mipsel crosscompiler from MIPS SDE
>
> This is a FAQ, please use a real mipsel-linux crosscompiler instead.
>
> 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 jan.pedersen@glaze.dk Tue Sep 27 20:25:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 20:26:19 +0100 (BST)
Received: from mail.glaze.se ([212.209.188.162]:30480 "HELO rocket.glaze.se")
	by ftp.linux-mips.org with SMTP id S8133807AbVI0TZ4 (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 20:25:56 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP id CAD8F376451
	for <linux-mips@linux-mips.org>; Tue, 27 Sep 2005 21:25:43 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	<linux-mips@linux-mips.org>
Subject: [patch] cfi: prevent kernel panic with cfi flash
Date:	Tue, 27 Sep 2005 21:25:42 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcXDmT38L9K3z4xqSdqdZy3CMt6npQ==
Message-Id: <20050927192543.CAD8F376451@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9057
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1217
Lines: 29

When using the cfi (common flash interface) driver, every word written to
the flash chips is followed by a operation complete poll. This poll is
intended to have a timeout of 1 ms. However this timeout is calculated by
HZ/1000, which happends to be 0 because HZ < 1000. The result of this is
that there will be just one poll for operation complete. If this single poll
fails, the kernel panics. This patch increases this timeout to HZ (1
second). This is far more than needed, but is preferred over a panic. This
fix is well tested and completely avoids the panic.

Signed-off-by: Jan Pedersen <jp@jp-embedded.com>
---
diff -Naur linux-2.4.31.org/drivers/mtd/chips/cfi_cmdset_0002.c
linux-2.4.31/drivers/mtd/chips/cfi_cmdset_0002.c
--- linux-2.4.31.org/drivers/mtd/chips/cfi_cmdset_0002.c	2004-11-17
06:54:21.000000000 -0500
+++ linux-2.4.31/drivers/mtd/chips/cfi_cmdset_0002.c	2005-08-22
12:14:17.000000000 -0400
@@ -510,7 +510,7 @@
 	   or tells us why it failed. */        
 	dq6 = CMD(1<<6);
 	dq5 = CMD(1<<5);
-	timeo = jiffies + (HZ/1000); /* setting timeout to 1ms for now */
+	timeo = jiffies + (HZ); /* setting timeout to 1s for now */
 		
 	oldstatus = cfi_read(map, adr);
 	status = cfi_read(map, adr);




From jan.pedersen@glaze.dk Tue Sep 27 20:46:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Sep 2005 20:47:17 +0100 (BST)
Received: from mail.glaze.se ([212.209.188.162]:31504 "HELO rocket.glaze.se")
	by ftp.linux-mips.org with SMTP id S8134392AbVI0Tqz (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Tue, 27 Sep 2005 20:46:55 +0100
Received: from IBMJP (unknown [10.42.1.6])
	by rocket.glaze.se (Postfix) with ESMTP id BB914376451
	for <linux-mips@linux-mips.org>; Tue, 27 Sep 2005 21:46:45 +0200 (CEST)
From:	"Jan Pedersen" <jan.pedersen@glaze.dk>
To:	<linux-mips@linux-mips.org>
Subject: [patch] cfi: removed warning message on expected behaivor
Date:	Tue, 27 Sep 2005 21:45:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 5 (Lowest)
X-MSMail-Priority: Low
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcXDnBGyK+lQCz6NQgKmvZ2YSgbPWg==
Importance: Low
Message-Id: <20050927194645.BB914376451@rocket.glaze.se>
Return-Path: <jan.pedersen@glaze.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9058
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jan.pedersen@glaze.dk
Precedence: bulk
X-list: linux-mips
Content-Length: 1393
Lines: 35

When an erase operation is in progress, the DQ5 (data bit 5 / exceeded
timing limit) pin on the flash chips may raise just before operation
complete is detected. This is expected behaivor because when the erase is
complete, DQ5 switches from 'exceeded timing limit' to 'data bit 5' which
therefore might be read as '1' just before operation complete is detected.
This fix is well tested.

Signed-off-by: Jan Pedersen <jp@jp-embedded.com>
---
diff -Naur linux-2.4.31.org/drivers/mtd/chips/cfi_cmdset_0002.c
linux-2.4.31/drivers/mtd/chips/cfi_cmdset_0002.c
--- linux-2.4.31.org/drivers/mtd/chips/cfi_cmdset_0002.c	2004-11-17
06:54:21.000000000 -0500
+++ linux-2.4.31/drivers/mtd/chips/cfi_cmdset_0002.c	2005-08-22
12:14:17.000000000 -0400
@@ -950,12 +950,8 @@
 		    oldstatus   = cfi_read( map, adr );
 		    status      = cfi_read( map, adr );
 		    
-		    if( ( oldstatus & 0x00FF ) == ( status & 0x00FF ) )
+		    if( ( oldstatus & 0x00FF ) != ( status & 0x00FF ) )
 		    {
-                printk( "Warning: DQ5 raised while erase operation was in
progress, but erase completed OK\n" ); 		    
-		    } 			
-			else
-            {
 			    /* DQ5 is active so we can do a reset and stop
the erase */
 				cfi_write(map, CMD(0xF0), chip->start);
                 printk( KERN_WARNING "Internal flash device timeout occured
or write operation was performed while flash was erasing\n" );




From yallain@avilinks.com Wed Sep 28 08:29:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 08:29:21 +0100 (BST)
Received: from paris5.amen.fr ([62.193.203.10]:34059 "EHLO paris5.amen.fr")
	by ftp.linux-mips.org with ESMTP id S8134126AbVI1H3E (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 08:29:04 +0100
Received: from firewall (46.237.98-84.rev.gaoland.net [84.98.237.46])
	by paris5.amen.fr (8.10.2/8.10.2) with ESMTP id j8S7T3v17392
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 09:29:03 +0200
Message-ID: <433A45BD.80408@avilinks.com>
Date:	Wed, 28 Sep 2005 09:26:53 +0200
From:	Yoann Allain <yallain@avilinks.com>
Organization: Avilinks
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: fr, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Compiling a 2.6 kernel for Mips
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
In-Reply-To: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <yallain@avilinks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9059
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yallain@avilinks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1443
Lines: 42

Hi,

I am no more a newbie but I still need some help to build kernels :
I am working on the Wintegra Evaluation Board (WEB777) and I used the 
2.4 kernel Wintegra gave me with the patch for that board.
I tried to adapt the patch for the 2.6 kernel but it doesn't work. I 
traced the kernel to find it crashed very early before displaying anything.
In fact the host processor makes an address and tries to read it but 
this makes an exception :

* Exception 0x02 (user) : TLB (load or instruction fetch) *
* in address: 80101ea8
ClockDiv2+0xe38:
[80101ea8] 8c820000 lw          r2,0x0000(r4)


r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  : 80360000
r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  : 8038df8c


I think this is a problem of host processor misconfiguration, but don't 
find out exactly what it is... To make the address in R4, the processor 
reads some zeroes where in 2.4 kernel, it doesn't and the address read 
in 2.4 is something like 0xbf010f1c.
I don't know if this can help but here are the few functions before crash:

kernel_entry
    J start_kernel
             cpu_probe() (WEB777 patch)
             prom_init() (WEB777 patch)
                   setup_prom_printf() (WEB777 patch)
                   wds_prom_printf() (WEB777 patch)
                            putPromChar() (WEB777 patch)
                            --> CRASH


Thanks a lot for your precious advices

Yoann




From anemo@mba.ocn.ne.jp Wed Sep 28 12:25:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 12:25:24 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:38171 "HELO
	topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP
	id S8133658AbVI1LZG (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Wed, 28 Sep 2005 12:25:06 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 Sep 2005 11:25:04 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id EBC0E1FE19;
	Wed, 28 Sep 2005 20:24:59 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id D6C061F1F6;
	Wed, 28 Sep 2005 20:24:59 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8SBOwoj016520;
	Wed, 28 Sep 2005 20:24:59 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Wed, 28 Sep 2005 20:24:58 +0900 (JST)
Message-Id: <20050928.202458.32344678.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: sync c-tx39.c with c-r4k.c
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
Organization: TOSHIBA Personal Computer System Corporation
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9060
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 963
Lines: 33

tx39_flush_cache_range() do nothing if !cpu_has_dc_aliases.  It should
flush d-cache and invalidate i-cache since TX39(H2) has separate I/D
cache.

Here is a patch.  

diff -u linux-mips/arch/mips/mm/c-tx39.c linux/arch/mips/mm/c-tx39.c
--- linux-mips/arch/mips/mm/c-tx39.c	2005-09-05 10:16:59.000000000 +0900
+++ linux/arch/mips/mm/c-tx39.c	2005-09-28 18:51:43.000000000 +0900
@@ -167,15 +167,16 @@
 static void tx39_flush_cache_range(struct vm_area_struct *vma,
 	unsigned long start, unsigned long end)
 {
-	struct mm_struct *mm = vma->vm_mm;
+	int exec;
 
-	if (!cpu_has_dc_aliases)
+	if (!(cpu_context(smp_processor_id(), vma->vm_mm)))
 		return;
 
-	if (cpu_context(smp_processor_id(), mm) != 0) {
+	exec = vma->vm_flags & VM_EXEC;
+	if (cpu_has_dc_aliases || exec)
 		tx39_blast_dcache();
+	if (exec)
 		tx39_blast_icache();
-	}
 }
 
 static void tx39_flush_cache_page(struct vm_area_struct *vma, unsigned long page, unsigned long pfn)

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Wed Sep 28 12:34:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 12:34:55 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:1830 "HELO
	topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP
	id S8133585AbVI1Led (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Wed, 28 Sep 2005 12:34:33 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 Sep 2005 11:34:31 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 4BC561FE1B;
	Wed, 28 Sep 2005 20:34:30 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 368941FE13;
	Wed, 28 Sep 2005 20:34:30 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8SBYToj016584;
	Wed, 28 Sep 2005 20:34:30 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Wed, 28 Sep 2005 20:34:29 +0900 (JST)
Message-Id: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: missing data cache flush for signal trampoline on fork
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9061
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3562
Lines: 128

Hi.  The attached test program which is heavily using signal and fork
occasionally killed by SIGSEG, etc.  When it was killed, PC is always
near the stack pointer.

This would happen on CPUs without MIPS_CACHE_IC_F_DC.  D-cache
aliasing is irrelevant.

1. To handle the signal (SIGUSR1), signal-trampoline code are written
to the stack page.

2. They are flushed to memory immediately and I-cache are invalidated.

3. If other thread called fork() before the signal handler is
executed, all writable page (including the stack page) are marked as
COW page.

4. When the user signal handler is to write to the stack, the page
will be copied to new physical page by copy_user_page(), but not
flushed to main memory.  copy_user_page() use kernel virtual address
to copy the data.

5. Then flush_cache_page() is called for the stack page, but it uses
user virtual address and Hit_Invalidate_Writeback_D.  This does not
flush the cache written by copy_user_page().

6. When returned from the user signal handler, the signal trampoline
code might not be written to main memory.  Garbage code will be
executed and the program die.

Here is a test program.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>

void sighandler(int sig)
{
	int a;
	*(volatile int *)&a = 0;
}

void *thread_func(void *arg)
{
	pid_t pid = getpid();
	struct sigaction act;
	memset(&act, 0, sizeof(act));
	act.sa_handler = sighandler;
	act.sa_flags = SA_NOMASK | SA_RESTART;
	sigaction(SIGUSR1, &act, 0);
	sig_count = 0;
	while (1)
		kill(pid, SIGUSR1);
}

int
main(int argc, char *argv[])
{
	int i;
	pid_t pid;
	pthread_t tid;
	for (i = 0; i < 4; i++)
		pthread_create(&tid, NULL, thread_func, NULL);
	for (i = 0; i < 1000; i++) {
		pid = fork();
		if (pid == -1) {
			perror("fork");
			exit(1);
		}
		if (pid)
			waitpid(pid, NULL, 0);
		else
			exit(0);
	}
	return 0;
}


If I used indexed-flush for executable page in flush_cache_page(), the
problem disappear.  Is this a right fix?


diff -u linux-mips/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-mips/arch/mips/mm/c-r4k.c	2005-09-22 10:38:23.000000000 +0900
+++ linux/arch/mips/mm/c-r4k.c	2005-09-28 18:50:56.000000000 +0900
@@ -409,15 +409,11 @@
 	 * for every cache flush operation.  So we do indexed flushes
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
-	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || (exec && !cpu_has_ic_fills_f_dc)) {
+	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID) &&
+	    !(exec && !cpu_has_ic_fills_f_dc)) {
+		if (cpu_has_dc_aliases) {
 			r4k_blast_dcache_page(page);
-			if (exec && !cpu_icache_snoops_remote_store)
-				r4k_blast_scache_page(page);
 		}
-		if (exec)
-			r4k_blast_icache_page(page);
-
 		return;
 	}
 
diff -u linux-mips/arch/mips/mm/c-tx39.c linux/arch/mips/mm/c-tx39.c
--- linux-mips/arch/mips/mm/c-tx39.c	2005-09-05 10:16:59.000000000 +0900
+++ linux/arch/mips/mm/c-tx39.c	2005-09-28 18:51:43.000000000 +0900
@@ -213,12 +213,10 @@
 	 * for every cache flush operation.  So we do indexed flushes
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
-	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || exec)
+	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID) &&
+	    !exec) {
+		if (cpu_has_dc_aliases)
 			tx39_blast_dcache_page(page);
-		if (exec)
-			tx39_blast_icache_page(page);
-
 		return;
 	}
 

---
Atsushi Nemoto

From anemo@mba.ocn.ne.jp Wed Sep 28 12:58:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 12:58:18 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:42268 "HELO
	topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP
	id S8133567AbVI1L6B (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Wed, 28 Sep 2005 12:58:01 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 Sep 2005 11:58:00 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id AC7ED1FE17;
	Wed, 28 Sep 2005 20:57:58 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 96F291FE0F;
	Wed, 28 Sep 2005 20:57:58 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8SBvwoj016658;
	Wed, 28 Sep 2005 20:57:58 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Wed, 28 Sep 2005 20:57:58 +0900 (JST)
Message-Id: <20050928.205758.32501424.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: Re: missing data cache flush for signal trampoline on fork
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
References: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9062
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1750
Lines: 44

>>>>> On Wed, 28 Sep 2005 20:34:29 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> If I used indexed-flush for executable page in
anemo> flush_cache_page(), the problem disappear.  Is this a right
anemo> fix?

Sorry, this would corrupt cpu_has_ic_fills_f_dc case.  Revised.

diff -u linux-mips/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-mips/arch/mips/mm/c-r4k.c	2005-09-22 10:38:23.000000000 +0900
+++ linux/arch/mips/mm/c-r4k.c	2005-09-28 20:55:55.000000000 +0900
@@ -409,8 +409,9 @@
 	 * for every cache flush operation.  So we do indexed flushes
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
-	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || (exec && !cpu_has_ic_fills_f_dc)) {
+	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID) &&
+	    !(exec && !cpu_has_ic_fills_f_dc)) {
+		if (cpu_has_dc_aliases) {
 			r4k_blast_dcache_page(page);
 			if (exec && !cpu_icache_snoops_remote_store)
 				r4k_blast_scache_page(page);
diff -u linux-mips/arch/mips/mm/c-tx39.c linux/arch/mips/mm/c-tx39.c
--- linux-mips/arch/mips/mm/c-tx39.c	2005-09-05 10:16:59.000000000 +0900
+++ linux/arch/mips/mm/c-tx39.c	2005-09-28 18:51:43.000000000 +0900
@@ -213,12 +213,10 @@
 	 * for every cache flush operation.  So we do indexed flushes
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
-	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || exec)
+	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID) &&
+	    !exec) {
+		if (cpu_has_dc_aliases)
 			tx39_blast_dcache_page(page);
-		if (exec)
-			tx39_blast_icache_page(page);
-
 		return;
 	}
 

---
Atsushi Nemoto

From florian.delizy@sagem.com Wed Sep 28 14:01:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 14:02:17 +0100 (BST)
Received: from ns2.sagem.com ([62.160.59.241]:19156 "EHLO mx2.sagem.com")
	by ftp.linux-mips.org with ESMTP id S8133577AbVI1NB7 (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 14:01:59 +0100
To:	Yoann Allain <yallain@avilinks.com>
Cc:	linux-mips@linux-mips.org
Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Compiling_a_2=2E6_kernel_for_Mips?=
MIME-Version: 1.0
Message-ID: <OF6AB06D9F.A4F86C60-ONC125708A.003730C5-C125708A.00479A09@sagem.com>
From:	Florian DELIZY <florian.delizy@sagem.com>
Date:	Wed, 28 Sep 2005 15:01:48 +0200
Content-Type: multipart/alternative; boundary="=_alternative 00479A07C125708A_="
Return-Path: <florian.delizy@sagem.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9063
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: florian.delizy@sagem.com
Precedence: bulk
X-list: linux-mips
Content-Length: 5817
Lines: 153

Message en plusieurs parties au format MIME
--=_alternative 00479A07C125708A_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Hi,

> I am no more a newbie but I still need some help to build kernels :
> I am working on the Wintegra Evaluation Board (WEB777) and I used the=20
> 2.4 kernel Wintegra gave me with the patch for that board.
> I tried to adapt the patch for the 2.6 kernel but it doesn't work. I=20
> traced the kernel to find it crashed very early before displaying=20
anything.
> In fact the host processor makes an address and tries to read it but=20
> this makes an exception :

> * Exception 0x02 (user) : TLB (load or instruction fetch) *
> * in address: 80101ea8
> ClockDiv2+0xe38:
> [80101ea8] 8c820000 lw          r2,0x0000(r4)


> r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  :=20
80360000
> r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  :=20
8038df8c

That would help a lot if you could objdump your kernel and give us 10=20
instructions before (at least)=20
and 10 instructions after it, you could try an :

mips-linux-objdump -DSz vmlinux | grep -U 20 '^\[80101ea8\]'

and send the output (that should ouput around 20 lines (which will=20
hopefully contain some C code also,
assu=F9ing that you compiled the code with debug informations. Moreover you=
=20
can also tell us in which=20
symbol (function) is located the address 0x80101ea8.


> I think this is a problem of host processor misconfiguration, but don't=20
> find out exactly what it is... To make the address in R4, the processor=20
> reads some zeroes where in 2.4 kernel, it doesn't and the address read=20
> in 2.4 is something like 0xbf010f1c.
> I don't know if this can help but here are the few functions before=20
crash:

> kernel=5Fentry
>    J start=5Fkernel
>             cpu=5Fprobe() (WEB777 patch)
>             prom=5Finit() (WEB777 patch)
>                   setup=5Fprom=5Fprintf() (WEB777 patch)
>                   wds=5Fprom=5Fprintf() (WEB777 patch)
>                            putPromChar() (WEB777 patch)
>                            --> CRASH

You should also start to figure out which variable/pointer anything is=20
consulted to get this adress (0x0000001c)=20
which might then help to understand you're problem.

Regards

Florian Delizy


--=_alternative 00479A07C125708A_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<br>
<br>
<br>
<br><font size=3D2 face=3D"Courier New">&gt; Hi,<br>
<br>
&gt; I am no more a newbie but I still need some help to build kernels :<br>
&gt; I am working on the Wintegra Evaluation Board (WEB777) and I used the =
<br>
&gt; 2.4 kernel Wintegra gave me with the patch for that board.<br>
&gt; I tried to adapt the patch for the 2.6 kernel but it doesn't work. I <=
br>
&gt; traced the kernel to find it crashed very early before displaying anyt=
hing.<br>
&gt; In fact the host processor makes an address and tries to read it but <=
br>
&gt; this makes an exception :<br>
<br>
&gt; * Exception 0x02 (user) : TLB (load or instruction fetch) *<br>
&gt; * in address: 80101ea8<br>
&gt; ClockDiv2+0xe38:<br>
&gt; [80101ea8] 8c820000 lw &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;r2,0x0000(r4)=
<br>
<br>
<br>
&gt; r0(zero): 00000000 r1(AT) &nbsp;: 1000fc00 r2(v0) &nbsp;: 0000001c r3(=
v1) &nbsp;: 80360000<br>
&gt; r4(a0) &nbsp;: 0000001c r5(a1) &nbsp;: 803919f0 r6(a2) &nbsp;: 0000000=
d r7(a3) &nbsp;: 8038df8c<br>
<br>
That would help a lot if you could objdump your kernel and give us 10 instr=
uctions before (at least) </font>
<br><font size=3D2 face=3D"Courier New">and 10 instructions after it, you c=
ould try an :</font>
<br>
<br><font size=3D2 face=3D"Courier New">mips-linux-objdump -DSz vmlinux | g=
rep -U 20 '^\[80101ea8\]'</font>
<br>
<br><font size=3D2 face=3D"Courier New">and send the output (that should ou=
put around 20 lines (which will hopefully contain some C code also,</font>
<br><font size=3D2 face=3D"Courier New">assu=F9ing that you compiled the co=
de with debug informations. Moreover you can also tell us in which </font>
<br><font size=3D2 face=3D"Courier New">symbol (function) is located the ad=
dress 0x80101ea8.</font>
<br>
<br><font size=3D2 face=3D"Courier New"><br>
&gt; I think this is a problem of host processor misconfiguration, but don'=
t </font>
<br><font size=3D2 face=3D"Courier New">&gt; find out exactly what it is...=
 To make the address in R4, the processor <br>
&gt; reads some zeroes where in 2.4 kernel, it doesn't and the address read=
 <br>
&gt; in 2.4 is something like 0xbf010f1c.<br>
&gt; I don't know if this can help but here are the few functions before cr=
ash:<br>
<br>
&gt; kernel=5Fentry<br>
&gt; &nbsp; &nbsp;J start=5Fkernel<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cpu=5Fprobe() (WEB777 patch)=
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; prom=5Finit() (WEB777 patch)=
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; setup=
=5Fprom=5Fprintf() (WEB777 patch)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wds=5Fp=
rom=5Fprintf() (WEB777 patch)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;putPromChar() (WEB777 patch)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;--&gt; CRASH</font>
<br>
<br><font size=3D2 face=3D"Courier New">You should also start to figure out=
 which variable/pointer anything is consulted to get this adress (0x0000001=
c) </font>
<br><font size=3D2 face=3D"Courier New">which might then help to understand=
 you're problem.<br>
<br>
Regards</font>
<br>
<br><font size=3D2 face=3D"Courier New">Florian Delizy</font>
<br>
<br>
--=_alternative 00479A07C125708A_=--

From yallain@avilinks.com Wed Sep 28 14:40:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 14:41:04 +0100 (BST)
Received: from paris5.amen.fr ([62.193.203.10]:53765 "EHLO paris5.amen.fr")
	by ftp.linux-mips.org with ESMTP id S8133585AbVI1Nks (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 14:40:48 +0100
Received: from firewall (46.237.98-84.rev.gaoland.net [84.98.237.46])
	by paris5.amen.fr (8.10.2/8.10.2) with ESMTP id j8SDekv20844;
	Wed, 28 Sep 2005 15:40:46 +0200
Message-ID: <433A9CD9.6040906@avilinks.com>
Date:	Wed, 28 Sep 2005 15:38:33 +0200
From:	Yoann Allain <yallain@avilinks.com>
Organization: Avilinks
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: fr, en
MIME-Version: 1.0
To:	Florian DELIZY <florian.delizy@sagem.com>
CC:	linux-mips@linux-mips.org
Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Compiling_a_2=2E6_kern?=
 =?ISO-8859-1?Q?el_for_Mips?=
References: <OF6AB06D9F.A4F86C60-ONC125708A.003730C5-C125708A.00479A09@sagem.com>
In-Reply-To: <OF6AB06D9F.A4F86C60-ONC125708A.003730C5-C125708A.00479A09@sagem.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <yallain@avilinks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9064
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yallain@avilinks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 4934
Lines: 128

Here is the function putPromChar in which I have the problem:

80101e70 <putPromChar>:
80101e70:       3c028039        lui     $v0,0x8039
80101e74:       244519f0        addiu   $a1,$v0,6640
80101e78:       8ca30014        lw      $v1,20($a1)
80101e7c:       00042600        sll     $a0,$a0,24
80101e80:       27bdfff0        addiu   $sp,$sp,-16
80101e84:       00043603        sra     $a2,$a0,24
80101e88:       10600012        beqz    $v1,80101ed4 <putPromChar+0x64>
80101e8c:       00001025        move    $v0,$zero
80101e90:       8ca20004        lw      $v0,4($a1)
80101e94:       3c038036        lui     $v1,0x8036
80101e98:       8c64c9a0        lw      $a0,-13920($v1)
80101e9c:       2442001c        addiu   $v0,$v0,28
80101ea0:       00822021        addu    $a0,$a0,$v0
80101ea4:       00000000        nop
80101ea8:       8c820000        lw      $v0,0($a0)
80101eac:       30420020        andi    $v0,$v0,0x20
80101eb0:       1040fffd        beqz    $v0,80101ea8 <putPromChar+0x38>
80101eb4:       3c028039        lui     $v0,0x8039
80101eb8:       8c4319f4        lw      $v1,6644($v0)
80101ebc:       3c048036        lui     $a0,0x8036
80101ec0:       8c82c9a0        lw      $v0,-13920($a0)
80101ec4:       24630004        addiu   $v1,$v1,4
80101ec8:       00431021        addu    $v0,$v0,$v1
80101ecc:       ac460000        sw      $a2,0($v0)
80101ed0:       24020001        li      $v0,1
80101ed4:       03e00008        jr      $ra
80101ed8:       27bd0010        addiu   $sp,$sp,16
80101edc:       00000000        nop

with WinMon (bootloader) I get this (this is perhaps more readable...):

[80101e70] 3c028039 lui         r2,0x8039		putPromChar
[80101e74] 244519f0 addiu       r5,r2,0x19f0
[80101e78] 8ca30014 lw          r3,0x0014(r5)
[80101e7c] 00042600 sll         r4,r4,24
[80101e80] 27bdfff0 addiu       r29,r29,0xfff0
[80101e84] 00043603 sra         r6,r4,24
[80101e88] 10600012 beq         r3,r0,0x0012
[80101e90] 8ca20004 lw          r2,0x0004(r5)           --> in 2.6 it reads 0 at address r5 + 0x4  
[80101e94] 3c038036 lui         r3,0x8036
[80101e98] 8c64c9a0 lw          r4,0xc9a0(r3)		--> in 2.6 it reads 0 at adress r3 + 0xc9a0
[80101e9c] 2442001c addiu       r2,r2,0x001c
[80101ea0] 00822021 addu        r4,r4,r2		==> in 2.4 it returns bf010f1c in r4
[80101ea8] 8c820000 lw          r2,0x0000(r4)

* Exception 0x02 (user) : TLB (load or instruction fetch) *
* in address: 80101ea8
ClockDiv2+0xe38:
[80101ea8] 8c820000 lw          r2,0x0000(r4)


r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  : 80360000
r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  : 8038df8c

I hope this will help and many thanks for your help!

Yoann



Florian DELIZY wrote:

>
>
>
>
> > Hi,
>
> > I am no more a newbie but I still need some help to build kernels :
> > I am working on the Wintegra Evaluation Board (WEB777) and I used the
> > 2.4 kernel Wintegra gave me with the patch for that board.
> > I tried to adapt the patch for the 2.6 kernel but it doesn't work. I
> > traced the kernel to find it crashed very early before displaying 
> anything.
> > In fact the host processor makes an address and tries to read it but
> > this makes an exception :
>
> > * Exception 0x02 (user) : TLB (load or instruction fetch) *
> > * in address: 80101ea8
> > ClockDiv2+0xe38:
> > [80101ea8] 8c820000 lw          r2,0x0000(r4)
>
>
> > r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  : 
> 80360000
> > r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  : 
> 8038df8c
>
> That would help a lot if you could objdump your kernel and give us 10 
> instructions before (at least)
> and 10 instructions after it, you could try an :
>
> mips-linux-objdump -DSz vmlinux | grep -U 20 '^\[80101ea8\]'
>
> and send the output (that should ouput around 20 lines (which will 
> hopefully contain some C code also,
> assuùing that you compiled the code with debug informations. Moreover 
> you can also tell us in which
> symbol (function) is located the address 0x80101ea8.
>
>
> > I think this is a problem of host processor misconfiguration, but don't
> > find out exactly what it is... To make the address in R4, the processor
> > reads some zeroes where in 2.4 kernel, it doesn't and the address read
> > in 2.4 is something like 0xbf010f1c.
> > I don't know if this can help but here are the few functions before 
> crash:
>
> > kernel_entry
> >    J start_kernel
> >             cpu_probe() (WEB777 patch)
> >             prom_init() (WEB777 patch)
> >                   setup_prom_printf() (WEB777 patch)
> >                   wds_prom_printf() (WEB777 patch)
> >                            putPromChar() (WEB777 patch)
> >                            --> CRASH
>
> You should also start to figure out which variable/pointer anything is 
> consulted to get this adress (0x0000001c)
> which might then help to understand you're problem.
>
> Regards
>
> Florian Delizy
>

From anemo@mba.ocn.ne.jp Wed Sep 28 16:11:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 16:11:40 +0100 (BST)
Received: from mba.ocn.ne.jp ([210.190.142.172]:13794 "HELO smtp.mba.ocn.ne.jp")
	by ftp.linux-mips.org with SMTP id S8133591AbVI1PLZ (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 16:11:25 +0100
Received: from localhost (p3123-ipad11funabasi.chiba.ocn.ne.jp [219.162.38.123])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 2CFAC951D; Thu, 29 Sep 2005 00:11:21 +0900 (JST)
Date:	Thu, 29 Sep 2005 00:09:59 +0900 (JST)
Message-Id: <20050929.000959.59464701.anemo@mba.ocn.ne.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: Re: missing data cache flush for signal trampoline on fork
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
References: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9065
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 529
Lines: 13

>>>>> On Wed, 28 Sep 2005 20:34:29 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:

anemo> 5. Then flush_cache_page() is called for the stack page, but it
anemo> uses user virtual address and Hit_Invalidate_Writeback_D.  This
anemo> does not flush the cache written by copy_user_page().

This was somewhat wrong.  The flush_cache_page() would flush old data
on the page allocated for the stack.  Anyway this does not flush the
cache written by copy_user_page() because new PTE is not established
yet.

---
Atsushi Nemoto

From macro@linux-mips.org Wed Sep 28 16:22:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 16:23:13 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:1292 "EHLO
	pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP
	id S8133397AbVI1PWw (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Wed, 28 Sep 2005 16:22:52 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DD93EF5A6F
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 17:22:46 +0200 (CEST)
Received: from pollux.ds.pg.gda.pl ([127.0.0.1])
 by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 05468-09 for <linux-mips@linux-mips.org>;
 Wed, 28 Sep 2005 17:22:46 +0200 (CEST)
Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 99F01F5A6E
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 17:22:46 +0200 (CEST)
Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6])
	by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id j8SFMo2S030961
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 17:22:50 +0200
Date:	Wed, 28 Sep 2005 16:22:59 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: TURBOchannel patches for drivers available for 2.6
Message-ID: <Pine.LNX.4.61L.0509281606370.18267@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9066
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1485
Lines: 27

Hello folks,

 It looks like development of the new generic TURBOchannel layer is a bit 
slow, but it's definitely meant to be the first significant change to be 
done for Linux 2.6 for systems supporting the bus.  Meanwhile, to 
encourage moving forward to 2.6, I have implemented changes necessary to 
the two drivers for PCI devices that are currently of use for TURBOchannel 
variations of the respective hardware.  They are available from my site 
and include support for the following devices:

1. The DEC FDDIcontroller/TURBOchannel family of FDDI network interfaces 
   (based on the PDQ/CAMEL chipset), comprising: DEFTA-FA, DEFTA-AA, 
   DEFTA-DA and DEFTA-UA.  The patch is available from: 
   "ftp://ftp3.ds.pg.gda.pl/people/macro/drivers/defxx/patch-mips-2.6.12-rc4-20050526-defta-25.gz".

2. The DEC ZLX-E1/2/3 family of graphics smart frame buffers (based on the 
   SFB+ ASIC, a functional equivalent of the 21030 or TGA), comprising: 
   PMAGD-A, PMAGD-B and PMAGD-C.  The patch is available from: 
   "ftp://ftp3.ds.pg.gda.pl/people/macro/drivers/tgafb/patch-mips-2.6.12-rc4-20050526-hx+-37.gz".

I have to regret these patches have only been tested with a kernel 
snapshot as denoted in the patch file names, but my intent is to keep them 
reasonably up to date as I update what I use for my development systems.  
I do hope there will not be many updates for these patches as they will be 
merged as soon as the generic TURBOchannel layer is implemented.

  Maciej

From ralf@linux-mips.org Wed Sep 28 19:37:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 19:37:58 +0100 (BST)
Received: from alg138.algor.co.uk ([62.254.210.138]:64676 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S8133576AbVI1Shn (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Wed, 28 Sep 2005 19:37:43 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8SIbWQA018887;
	Wed, 28 Sep 2005 20:37:32 +0200
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8SIbVEU018886;
	Wed, 28 Sep 2005 19:37:31 +0100
Date:	Wed, 28 Sep 2005 19:37:31 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	oski <oski2001@hotmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Compiling a kernel for ibm z50
Message-ID: <20050928183731.GA18480@linux-mips.org>
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9067
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 609
Lines: 16

On Tue, Sep 27, 2005 at 06:19:51PM +0100, oski wrote:

> This is my set up:
> -An old Pentium II box with Redhat 8
> -Downloaded linux-2.6.13.mipscvs-20050904 from www.longlandclan...and bzip2
> and tar into /usr/src.
> -Installed the mipsel crosscompiler from MIPS SDE
> -After make config, when trying to make dep, I get a warning: make dep is
> unnecessary now.
> -Doing a ls arch/mips/boot I get a file called "compressed" with only a
> folder called "CVS" .

That's because who made that tarball didn't know his way around CVS enough
to supply a -P option.  Nothing to worry, just extra clutter.

  Ralf

From jtm@smoothsmoothie.com Wed Sep 28 21:52:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 21:53:06 +0100 (BST)
Received: from a1.ldhosting.net ([72.29.96.10]:34234 "EHLO astro.ldhosting.net")
	by ftp.linux-mips.org with ESMTP id S8133594AbVI1Uwu (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 21:52:50 +0100
Received: from [172.25.13.122] (adsl-69-149-118-47.dsl.austtx.swbell.net [69.149.118.47])
	by astro.ldhosting.net (Postfix) with ESMTP id 9D3411000C5
	for <linux-mips@linux-mips.org>; Wed, 28 Sep 2005 15:52:43 -0500 (CDT)
Message-ID: <433B0299.8080507@smoothsmoothie.com>
Date:	Wed, 28 Sep 2005 15:52:41 -0500
From:	Jay Monkman <jtm@smoothsmoothie.com>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050817)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: USB on AU1550
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <jtm@smoothsmoothie.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9068
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jtm@smoothsmoothie.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1969
Lines: 48

I'm trying to get USB working on my AU1550 board, and I'm getting an error I
don't understand. I've searched the web and the mailing list archives, but
haven't found anything relevant.

I'm using 2.6.12, in big-endian mode.

After the kernel comes up, I plug in a USB flash drive and get this on the console:
    au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus [1] = 0x00010101 CSC
PPS CCS
    hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s
    hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
    au1xxx-ohci au1xxx-ohci.0: GetStatus roothub.portstatus [1] = 0x00100103
PRSC PPS PES CCS
    usb 1-2: new full speed USB device using au1xxx-ohci and address 2
    au1xxx-ohci au1xxx-ohci.0: Unlink after no-IRQ?  Controller is probably
using the wrong IRQ.


This is the comment in the code before that printk():
	/* IRQ setup can easily be broken so that USB controllers
	 * never get completion IRQs ... maybe even the ones we need to
	 * finish unlinking the initial failed usb_set_address()
	 * or device descriptor fetch.
	 */
	if (!hcd->saw_irq && hcd->self.root_hub != urb->dev) {
		dev_warn (hcd->self.controller, "Unlink after no-IRQ?  "
			"Controller is probably using the wrong IRQ."
			"\n");
		hcd->saw_irq = 1;
	}

When I get here in the code, hcd->saw_irq is 0, and it looks like this function
(hcd_unlink_urb()) is getting called from run_timer_softirq(), so I guess I'm
not getting the interrupt. However, immediately after returning, usb_hcd_irq()
does get called. As far as I can tell, the interrupt gets serviced as soon as
hcd_unlink_urb returns.

It looks like the timer function causing this is timeout_kill(), initialized in
usb_start_wait_urb() which has this comment:
	// Starts urb and waits for completion or timeout
	// note that this call is NOT interruptible, while
	// many device driver i/o requests should be interruptible



Can anyone point me in the right direction to get this working?

Thanks.

From drow@nevyn.them.org Wed Sep 28 23:11:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 28 Sep 2005 23:11:37 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:34983 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133602AbVI1WLR (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Wed, 28 Sep 2005 23:11:17 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EKk8x-000624-FY; Wed, 28 Sep 2005 18:11:15 -0400
Date:	Wed, 28 Sep 2005 18:11:15 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: [PATCH] Revise MIPS64 ptrace interface
Message-ID: <20050928221115.GA22817@nevyn.them.org>
References: <20050922182601.GA10829@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050922182601.GA10829@nevyn.them.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9069
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 10553
Lines: 347

Change the N32 debugging ABI to something more sane, and add support
for o32 and n32 debuggers to trace n64 programs.

Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
---

I've now tested everything except the actual _3264 operations, which
were copied from PPC anyway and I have reasonable faith in.  So here's
a final patch.  If this seems reasonable to everyone, I'd like for it
to be merged, and then I can submit the glibc and gdb bits.

The patch itself is below.  If you want to test it, at
http://return.false.org/~drow/mips/ you can find:

  gdb-2005-09-28-HEAD-MIPS64-DEBUG.tar.gz
  glibc-2005-09-28-HEAD-MIPS64-NPTL.tar.gz
  linux-2005-09-28-sentosa-n32-ptrace.tar.gz

These are patches against linux-mips.org HEAD, glibc HEAD, and gdb HEAD
(all last week) that allow n32 and n64 debugging.  For n64 debugging
you'll need to remove .debug_frame/.eh_frame first since I haven't
looked at those bits of GDB / GCC yet.

Index: linux/arch/mips/kernel/ptrace32.c
===================================================================
--- linux.orig/arch/mips/kernel/ptrace32.c	2005-09-21 14:48:02.000000000 -0400
+++ linux/arch/mips/kernel/ptrace32.c	2005-09-28 15:18:29.000000000 -0400
@@ -35,6 +35,12 @@
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
 
+int ptrace_getregs (struct task_struct *child, __s64 __user *data);
+int ptrace_setregs (struct task_struct *child, __s64 __user *data);
+
+int ptrace_getfpregs (struct task_struct *child, __u32 __user *data);
+int ptrace_setfpregs (struct task_struct *child, __u32 __user *data);
+
 /*
  * Tracing a 32-bit process with a 64-bit strace and vice versa will not
  * work.  I don't know how to fix this.
@@ -99,6 +105,35 @@ asmlinkage int sys32_ptrace(int request,
 		break;
 	}
 
+	/*
+	 * Read 4 bytes of the other process' storage
+	 *  data is a pointer specifying where the user wants the
+	 *	4 bytes copied into
+	 *  addr is a pointer in the user's storage that contains an 8 byte
+	 *	address in the other process of the 4 bytes that is to be read
+	 * (this is run in a 32-bit process looking at a 64-bit process)
+	 * when I and D space are separate, these will need to be fixed.
+	 */
+	case PTRACE_PEEKTEXT_3264:
+	case PTRACE_PEEKDATA_3264: {
+		u32 tmp;
+		int copied;
+		u32 __user * addrOthers;
+
+		ret = -EIO;
+
+		/* Get the addr in the other process that we want to read */
+		if (get_user(addrOthers, (u32 __user * __user *) (unsigned long) addr) != 0)
+			break;
+
+		copied = access_process_vm(child, (u64)addrOthers, &tmp,
+				sizeof(tmp), 0);
+		if (copied != sizeof(tmp))
+			break;
+		ret = put_user(tmp, (u32 __user *) (unsigned long) data);
+		break;
+	}
+
 	/* Read the word at location addr in the USER area. */
 	case PTRACE_PEEKUSR: {
 		struct pt_regs *regs;
@@ -202,6 +237,31 @@ asmlinkage int sys32_ptrace(int request,
 		ret = -EIO;
 		break;
 
+	/*
+	 * Write 4 bytes into the other process' storage
+	 *  data is the 4 bytes that the user wants written
+	 *  addr is a pointer in the user's storage that contains an
+	 *	8 byte address in the other process where the 4 bytes
+	 *	that is to be written
+	 * (this is run in a 32-bit process looking at a 64-bit process)
+	 * when I and D space are separate, these will need to be fixed.
+	 */
+	case PTRACE_POKETEXT_3264:
+	case PTRACE_POKEDATA_3264: {
+		u32 __user * addrOthers;
+
+		/* Get the addr in the other process that we want to write into */
+		ret = -EIO;
+		if (get_user(addrOthers, (u32 __user * __user *) (unsigned long) addr) != 0)
+			break;
+		ret = 0;
+		if (access_process_vm(child, (u64)addrOthers, &data,
+					sizeof(data), 1) == sizeof(data))
+			break;
+		ret = -EIO;
+		break;
+	}
+
 	case PTRACE_POKEUSR: {
 		struct pt_regs *regs;
 		ret = 0;
@@ -276,6 +336,22 @@ asmlinkage int sys32_ptrace(int request,
 		break;
 		}
 
+	case PTRACE_GETREGS:
+		ret = ptrace_getregs (child, (__u64 __user *) (__u64) data);
+		break;
+
+	case PTRACE_SETREGS:
+		ret = ptrace_setregs (child, (__u64 __user *) (__u64) data);
+		break;
+
+	case PTRACE_GETFPREGS:
+		ret = ptrace_getfpregs (child, (__u32 __user *) (__u64) data);
+		break;
+
+	case PTRACE_SETFPREGS:
+		ret = ptrace_setfpregs (child, (__u32 __user *) (__u64) data);
+		break;
+
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
 		ret = -EIO;
@@ -320,6 +396,11 @@ asmlinkage int sys32_ptrace(int request,
 			       (unsigned int __user *) (unsigned long) data);
 		break;
 
+	case PTRACE_GET_THREAD_AREA_3264:
+		ret = put_user(child->thread_info->tp_value,
+				(unsigned long __user *) (unsigned long) data);
+		break;
+
 	default:
 		ret = ptrace_request(child, request, addr, data);
 		break;
Index: linux/include/asm-mips/ptrace.h
===================================================================
--- linux.orig/include/asm-mips/ptrace.h	2005-09-21 14:48:02.000000000 -0400
+++ linux/include/asm-mips/ptrace.h	2005-09-28 15:15:14.000000000 -0400
@@ -48,10 +48,10 @@ struct pt_regs {
 };
 
 /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
-/* #define PTRACE_GETREGS		12 */
-/* #define PTRACE_SETREGS		13 */
-/* #define PTRACE_GETFPREGS		14 */
-/* #define PTRACE_SETFPREGS		15 */
+#define PTRACE_GETREGS		12
+#define PTRACE_SETREGS		13
+#define PTRACE_GETFPREGS		14
+#define PTRACE_SETFPREGS		15
 /* #define PTRACE_GETFPXREGS		18 */
 /* #define PTRACE_SETFPXREGS		19 */
 
@@ -60,6 +60,13 @@ struct pt_regs {
 #define PTRACE_GET_THREAD_AREA	25
 #define PTRACE_SET_THREAD_AREA	26
 
+/* Calls to trace a 64bit program from a 32bit program.  */
+#define PTRACE_PEEKTEXT_3264	0xc0
+#define PTRACE_PEEKDATA_3264	0xc1
+#define PTRACE_POKETEXT_3264	0xc2
+#define PTRACE_POKEDATA_3264	0xc3
+#define PTRACE_GET_THREAD_AREA_3264	0xc4
+
 #ifdef __KERNEL__
 
 #include <linux/linkage.h>
Index: linux/arch/mips/kernel/scall64-n32.S
===================================================================
--- linux.orig/arch/mips/kernel/scall64-n32.S	2005-09-21 09:34:45.000000000 -0400
+++ linux/arch/mips/kernel/scall64-n32.S	2005-09-22 14:04:19.000000000 -0400
@@ -216,7 +216,7 @@ EXPORT(sysn32_call_table)
 	PTR	compat_sys_getrusage
 	PTR	sys32_sysinfo
 	PTR	compat_sys_times
-	PTR	sys_ptrace
+	PTR	sys32_ptrace
 	PTR	sys_getuid			/* 6100 */
 	PTR	sys_syslog
 	PTR	sys_getgid
Index: linux/arch/mips/kernel/ptrace.c
===================================================================
--- linux.orig/arch/mips/kernel/ptrace.c	2005-09-22 14:11:07.000000000 -0400
+++ linux/arch/mips/kernel/ptrace.c	2005-09-28 15:17:23.000000000 -0400
@@ -38,6 +38,7 @@
 #include <asm/system.h>
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
+#include <asm/reg.h>
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -49,6 +50,118 @@ void ptrace_disable(struct task_struct *
 	/* Nothing to do.. */
 }
 
+/*
+ * Read a general register set.  We always use the 64-bit format, even
+ * for 32-bit kernels and for 32-bit processes on a 64-bit kernel.
+ * Registers are sign extended to fill the available space.
+ */
+int ptrace_getregs (struct task_struct *child, __s64 __user *data)
+{
+	struct pt_regs *regs;
+	int i;
+
+	if (!access_ok(VERIFY_WRITE, data, 38 * 8))
+		return -EIO;
+
+	regs = (struct pt_regs *) ((unsigned long) child->thread_info +
+	       THREAD_SIZE - 32 - sizeof(struct pt_regs));
+
+	for (i = 0; i < 32; i++)
+		__put_user (regs->regs[i], data + i);
+	__put_user (regs->lo, data + EF_LO - EF_R0);
+	__put_user (regs->hi, data + EF_HI - EF_R0);
+	__put_user (regs->cp0_epc, data + EF_CP0_EPC - EF_R0);
+	__put_user (regs->cp0_badvaddr, data + EF_CP0_BADVADDR - EF_R0);
+	__put_user (regs->cp0_status, data + EF_CP0_STATUS - EF_R0);
+	__put_user (regs->cp0_cause, data + EF_CP0_CAUSE - EF_R0);
+
+	return 0;
+}
+
+/*
+ * Write a general register set.  As for PTRACE_GETREGS, we always use
+ * the 64-bit format.  On a 32-bit kernel only the lower order half
+ * (according to endianness) will be used.
+ */
+int ptrace_setregs (struct task_struct *child, __s64 __user *data)
+{
+	struct pt_regs *regs;
+	int i;
+
+	if (!access_ok(VERIFY_READ, data, 38 * 8))
+		return -EIO;
+
+	regs = (struct pt_regs *) ((unsigned long) child->thread_info +
+	       THREAD_SIZE - 32 - sizeof(struct pt_regs));
+
+	for (i = 0; i < 32; i++)
+		__get_user (regs->regs[i], data + i);
+	__get_user (regs->lo, data + EF_LO - EF_R0);
+	__get_user (regs->hi, data + EF_HI - EF_R0);
+	__get_user (regs->cp0_epc, data + EF_CP0_EPC - EF_R0);
+
+	/* badvaddr, status, and cause may not be written.  */
+
+	return 0;
+}
+
+int ptrace_getfpregs (struct task_struct *child, __u32 __user *data)
+{
+	int i;
+
+	if (!access_ok(VERIFY_WRITE, data, 33 * 8))
+		return -EIO;
+
+	if (tsk_used_math(child)) {
+		fpureg_t *fregs = get_fpu_regs(child);
+		for (i = 0; i < 32; i++)
+			__put_user (fregs[i], i + (__u64 __user *) data);
+	} else {
+		for (i = 0; i < 32; i++)
+			__put_user ((__u64) -1, i + (__u64 __user *) data);
+	}
+
+	if (cpu_has_fpu) {
+		unsigned int flags, tmp;
+
+		__put_user (child->thread.fpu.hard.fcr31, data + 64);
+
+		flags = read_c0_status();
+		__enable_fpu();
+		__asm__ __volatile__("cfc1\t%0,$0" : "=r" (tmp));
+		write_c0_status(flags);
+		__put_user (tmp, data + 65);
+	} else {
+		__put_user (child->thread.fpu.soft.fcr31, data + 64);
+		__put_user ((__u32) 0, data + 65);
+	}
+
+	return 0;
+}
+
+int ptrace_setfpregs (struct task_struct *child, __u32 __user *data)
+{
+	fpureg_t *fregs;
+	int i;
+
+	if (!access_ok(VERIFY_READ, data, 33 * 8))
+		return -EIO;
+
+	fregs = get_fpu_regs(child);
+
+	for (i = 0; i < 32; i++)
+		__get_user (fregs[i], i + (__u64 __user *) data);
+
+	if (cpu_has_fpu)
+		__get_user (child->thread.fpu.hard.fcr31, data + 64);
+	else
+		__get_user (child->thread.fpu.soft.fcr31, data + 64);
+
+	/* FIR may not be written.  */
+
+	return 0;
+}
+
 asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
 {
 	struct task_struct *child;
@@ -300,6 +413,22 @@ asmlinkage int sys_ptrace(long request, 
 		break;
 		}
 
+	case PTRACE_GETREGS:
+		ret = ptrace_getregs (child, (__u64 __user *) data);
+		break;
+
+	case PTRACE_SETREGS:
+		ret = ptrace_setregs (child, (__u64 __user *) data);
+		break;
+
+	case PTRACE_GETFPREGS:
+		ret = ptrace_getfpregs (child, (__u32 __user *) data);
+		break;
+
+	case PTRACE_SETFPREGS:
+		ret = ptrace_setfpregs (child, (__u32 __user *) data);
+		break;
+
 	case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
 	case PTRACE_CONT: { /* restart after signal. */
 		ret = -EIO;

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From fosterb@uoguelph.ca Thu Sep 29 07:21:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 07:21:34 +0100 (BST)
Received: from mailhub.cs.uoguelph.ca ([131.104.96.75]:60804 "EHLO
	mailhub.cs.uoguelph.ca") by ftp.linux-mips.org with ESMTP
	id S8133627AbVI2GVO (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 07:21:14 +0100
Received: from batman.cs.uoguelph.ca (batman.cs.uoguelph.ca [131.104.93.48])
	by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j8T6L39j013960;
	Thu, 29 Sep 2005 02:21:03 -0400
Received: from beddie.cis.uoguelph.ca (marvin.cis.uoguelph.ca [131.104.48.131])
	by batman.cs.uoguelph.ca (8.13.4/8.13.4) with ESMTP id j8T6L105020718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 29 Sep 2005 02:21:01 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by beddie.cis.uoguelph.ca (Postfix) with ESMTP id C26BD42404;
	Thu, 29 Sep 2005 02:20:54 -0400 (EDT)
Received: from beddie.cis.uoguelph.ca ([127.0.0.1])
	by localhost (beddie [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 03755-10; Thu, 29 Sep 2005 02:20:53 -0400 (EDT)
Received: from [192.168.0.103] (CPE001217cc2ab6-CM001371143eca.cpe.net.cable.rogers.com [70.30.137.118])
	by beddie.cis.uoguelph.ca (Postfix) with ESMTP id A2327423EE;
	Thu, 29 Sep 2005 02:20:53 -0400 (EDT)
Message-ID: <433B87CE.1060509@uoguelph.ca>
Date:	Thu, 29 Sep 2005 02:21:02 -0400
From:	Brett Foster <fosterb@uoguelph.ca>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Yoann Allain <yallain@avilinks.com>
CC:	linux-mips@linux-mips.org
Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Compiling_a_2=2E6_kern?=
 =?ISO-8859-1?Q?el_for_Mips?=
References: <OF6AB06D9F.A4F86C60-ONC125708A.003730C5-C125708A.00479A09@sagem.com> <433A9CD9.6040906@avilinks.com>
In-Reply-To: <433A9CD9.6040906@avilinks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cs-club.org
X-Scanned-By: MIMEDefang 2.52 on 131.104.96.75
X-Scanned-By: MIMEDefang 2.52 on 131.104.93.48
Return-Path: <fosterb@uoguelph.ca>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9070
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: fosterb@uoguelph.ca
Precedence: bulk
X-list: linux-mips
Content-Length: 3197
Lines: 74

Yoann Allain wrote:

> Here is the function putPromChar in which I have the problem:
>
> 80101e70 <putPromChar>:
> 80101e70:       3c028039        lui     $v0,0x8039
> 80101e74:       244519f0        addiu   $a1,$v0,6640
> 80101e78:       8ca30014        lw      $v1,20($a1)
> 80101e7c:       00042600        sll     $a0,$a0,24
> 80101e80:       27bdfff0        addiu   $sp,$sp,-16
> 80101e84:       00043603        sra     $a2,$a0,24
> 80101e88:       10600012        beqz    $v1,80101ed4 <putPromChar+0x64>
> 80101e8c:       00001025        move    $v0,$zero
> 80101e90:       8ca20004        lw      $v0,4($a1)
> 80101e94:       3c038036        lui     $v1,0x8036
> 80101e98:       8c64c9a0        lw      $a0,-13920($v1)
> 80101e9c:       2442001c        addiu   $v0,$v0,28
> 80101ea0:       00822021        addu    $a0,$a0,$v0
> 80101ea4:       00000000        nop
> 80101ea8:       8c820000        lw      $v0,0($a0)
> 80101eac:       30420020        andi    $v0,$v0,0x20
> 80101eb0:       1040fffd        beqz    $v0,80101ea8 <putPromChar+0x38>
> 80101eb4:       3c028039        lui     $v0,0x8039
> 80101eb8:       8c4319f4        lw      $v1,6644($v0)
> 80101ebc:       3c048036        lui     $a0,0x8036
> 80101ec0:       8c82c9a0        lw      $v0,-13920($a0)
> 80101ec4:       24630004        addiu   $v1,$v1,4
> 80101ec8:       00431021        addu    $v0,$v0,$v1
> 80101ecc:       ac460000        sw      $a2,0($v0)
> 80101ed0:       24020001        li      $v0,1
> 80101ed4:       03e00008        jr      $ra
> 80101ed8:       27bd0010        addiu   $sp,$sp,16
> 80101edc:       00000000        nop
>
> with WinMon (bootloader) I get this (this is perhaps more readable...):
>
> [80101e70] 3c028039 lui         r2,0x8039        putPromChar
> [80101e74] 244519f0 addiu       r5,r2,0x19f0
> [80101e78] 8ca30014 lw          r3,0x0014(r5)
> [80101e7c] 00042600 sll         r4,r4,24
> [80101e80] 27bdfff0 addiu       r29,r29,0xfff0
> [80101e84] 00043603 sra         r6,r4,24
> [80101e88] 10600012 beq         r3,r0,0x0012
> [80101e90] 8ca20004 lw          r2,0x0004(r5)           --> in 2.6 it 
> reads 0 at address r5 + 0x4  [80101e94] 3c038036 lui         r3,0x8036
> [80101e98] 8c64c9a0 lw          r4,0xc9a0(r3)        --> in 2.6 it 
> reads 0 at adress r3 + 0xc9a0
> [80101e9c] 2442001c addiu       r2,r2,0x001c
> [80101ea0] 00822021 addu        r4,r4,r2        ==> in 2.4 it returns 
> bf010f1c in r4
> [80101ea8] 8c820000 lw          r2,0x0000(r4)
>
> * Exception 0x02 (user) : TLB (load or instruction fetch) *
> * in address: 80101ea8
> ClockDiv2+0xe38:
> [80101ea8] 8c820000 lw          r2,0x0000(r4)
>
>
> r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  : 
> 80360000
> r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  : 
> 8038df8c
>
> I hope this will help and many thanks for your help!
>
> Yoann

I traced through some of put character function this morning... I didn't 
finish, but I thought it looked like some data structure wasn't 
initialized. Perhaps you can figure out exactly what line the bad load 
belongs to in the C source, and see what structure that is. -- If there 
is a data structure -- I could just be crazy. ;)

Brett

From Eckhardt@satorlaser.com Thu Sep 29 08:08:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 08:09:06 +0100 (BST)
Received: from mail.domino-uk.com ([193.131.116.193]:6405 "EHLO
	vMIMEsweeper.dps.local") by ftp.linux-mips.org with ESMTP
	id S8133429AbVI2HIs convert rfc822-to-8bit (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 29 Sep 2005 08:08:48 +0100
Received: from dps-exchange1.dps.local (dps-exchange1) by vMIMEsweeper.dps.local
 (Clearswift SMTPRS 5.0.4) with ESMTP id <T73ad55e998c18374c1824@vMIMEsweeper.dps.local> for <linux-mips@linux-mips.org>;
 Thu, 29 Sep 2005 08:08:47 +0100
Received: from emea-exchange3.emea.dps.local ([192.168.50.10]) by dps-exchange1.dps.local with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 29 Sep 2005 08:08:48 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Floating point performance
Date:	Thu, 29 Sep 2005 09:08:47 +0200
Message-ID: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Floating point performance
Thread-Index: AcXDPCy3Fq71sgDySrOF/eAv33QsDwBiLs4g
From:	"Ulrich Eckhardt" <Eckhardt@satorlaser.com>
To:	<linux-mips@linux-mips.org>
X-OriginalArrivalTime: 29 Sep 2005 07:08:48.0183 (UTC) FILETIME=[A345EC70:01C5C4C4]
Return-Path: <Eckhardt@satorlaser.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9071
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Eckhardt@satorlaser.com
Precedence: bulk
X-list: linux-mips
Content-Length: 648
Lines: 12

(Sorry if this mail is garbled, I'm forced to use a sub-par client)

Matej Kupljen wrote:
> I've built soft float toolchain (with crosstool) and then build
> MPlayer with it. The performance is very low. I cannot even play the
> mp3 file with MPlayer on DBAU1200 with 400MHz CPU!
[...]
> Any other suggestions?

I'm not sure what you are doing, but if you only want to play music, I'd use Ogg Vorbis instead, which has a decoder that only uses integer arithmetic for exactly the case of FPU-less machines and the Au1200. I could also imagine an MP3 decoder written for integer only being written somewhere, but I don't know anything about it.

Uli

From matej.kupljen@ultra.si Thu Sep 29 10:08:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 10:08:41 +0100 (BST)
Received: from deliver-1.mx.triera.net ([213.161.0.31]:9170 "HELO
	deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP
	id S8133625AbVI2JIK (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 10:08:10 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 38788C07B;
	Thu, 29 Sep 2005 11:07:54 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id BC4301BC089;
	Thu, 29 Sep 2005 11:07:55 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 0013E1A18B0;
	Thu, 29 Sep 2005 11:07:55 +0200 (CEST)
Subject: Re: USB on AU1550
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	Jay Monkman <jtm@smoothsmoothie.com>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <433B0299.8080507@smoothsmoothie.com>
References: <433B0299.8080507@smoothsmoothie.com>
Content-Type: text/plain
Date:	Thu, 29 Sep 2005 11:07:11 +0200
Message-Id: <1127984831.10179.6.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9072
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 2344
Lines: 61

Hi

> I'm trying to get USB working on my AU1550 board, and I'm getting an error I
> don't understand. I've searched the web and the mailing list archives, but
> haven't found anything relevant.

Not the answer to you question, but I have some problems with USB on
AU1200 board too. I use AirStar2 USB card (this is DVB-T card) and it
is recognized by AU1200 and can communicate with it. I can tune to 
transporder, but the data (transport stream) is not send from the
USB card. 
The card conforms to USB 1.1. 
I tried it on a PC running Linux and it works fine.

AU1200 kernel: 2.6.11, PC kernel: 2.6.13.2.

Any thoughts?

BR,
Matej

P.S.: This is the log:
----------------------------------------------------------------------------------
flexcop_usb: running at FULL speed.
DVB: registering new adapter (FlexCop Digital TV device).
f010
b2c2-flexcop: MAC address = <DELETED>
b2c2-flexcop: found the mt352 at i2c address: 0x0f
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'USB'
bus controlled by a 'FlexCopIII' complete
creating 4 iso-urbs with 4 frames each of 1023 bytes size = 16368.
initializing and submitting urb no. 0 (buf_offset: 0).
urb no: 0, frame: 0, frame_offset: 0
urb no: 0, frame: 1, frame_offset: 1023
urb no: 0, frame: 2, frame_offset: 2046
urb no: 0, frame: 3, frame_offset: 3069
submitted urb no. 0.
initializing and submitting urb no. 1 (buf_offset: 4092).
urb no: 1, frame: 0, frame_offset: 0
urb no: 1, frame: 1, frame_offset: 1023
urb no: 1, frame: 2, frame_offset: 2046
urb no: 1, frame: 3, frame_offset: 3069
submitted urb no. 1.
initializing and submitting urb no. 2 (buf_offset: 8184).
urb no: 2, frame: 0, frame_offset: 0
urb no: 2, frame: 1, frame_offset: 1023
urb no: 2, frame: 2, frame_offset: 2046
urb no: 2, frame: 3, frame_offset: 3069
submitted urb no. 2.
initializing and submitting urb no. 3 (buf_offset: 12276).
urb no: 3, frame: 0, frame_offset: 0
urb no: 3, frame: 1, frame_offset: 1023
urb no: 3, frame: 2, frame_offset: 2046
urb no: 3, frame: 3, frame_offset: 3069
submitted urb no. 3.
flexcop_usb: Technisat/B2C2 FlexCop II/IIb/III Digital TV USB Driver
successfully initialized and connected.
usbcore: registered new driver b2c2_flexcop_usb
----------------------------------------------------------------------------------


From matej.kupljen@ultra.si Thu Sep 29 12:17:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 12:18:05 +0100 (BST)
Received: from deliver-1.mx.triera.net ([213.161.0.31]:38375 "HELO
	deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP
	id S8133635AbVI2LRt (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 12:17:49 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id C3CBDC063;
	Thu, 29 Sep 2005 13:17:22 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id F01231BC081;
	Thu, 29 Sep 2005 13:17:24 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 4D7C71A18B1;
	Thu, 29 Sep 2005 13:17:25 +0200 (CEST)
Subject: RE: Floating point performance
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	Ulrich Eckhardt <Eckhardt@satorlaser.com>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
Content-Type: text/plain
Date:	Thu, 29 Sep 2005 13:16:40 +0200
Message-Id: <1127992600.10179.19.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9073
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 1268
Lines: 35

Hi

> > I've built soft float toolchain (with crosstool) and then build
> > MPlayer with it. The performance is very low. I cannot even play the
> > mp3 file with MPlayer on DBAU1200 with 400MHz CPU!
> [...]
> > Any other suggestions?
> 
> I'm not sure what you are doing, but if you only want to play music, 
> I'd use Ogg Vorbis instead, which has a decoder that only uses integer 
> arithmetic for exactly the case of FPU-less machines and the Au1200. 
> I could also imagine an MP3 decoder written for integer only being 
> written somewhere, but I don't know anything about it.

Yes, I can use madplay (libmad) for music only, which uses int
arithmetics (also special version for MIPS).

But I also want to play video and currently I am testing this with
MPlayer (maybe I'll add support for MAE, sometime in the future).
Then I found out, that MPlayer can use libmad for MP3 and it
works great know.

Now I'll try to write XV driver for MAE backend so I'll have
HW accelerated Color Space Conversion (form YV12->RGB) and
Scaling. 

I thought that SF *should* be relatively fast, because I have
experience with it on ARM, where Nicolas Pitre wrote amazing 
SF support for the glibc.
How can we speed-up SF on MIPS? 
Does anybody have some suggestions?

BR,
Matej


From greg.weeks@timesys.com Thu Sep 29 12:31:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 12:31:48 +0100 (BST)
Received: from mail.timesys.com ([65.117.135.102]:43490 "EHLO
	exchange.timesys.com") by ftp.linux-mips.org with ESMTP
	id S8133635AbVI2Lb2 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 12:31:28 +0100
Received: from [192.168.2.27] ([192.168.2.27]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 29 Sep 2005 07:29:14 -0400
Message-ID: <433BD08E.1020402@timesys.com>
Date:	Thu, 29 Sep 2005 07:31:26 -0400
From:	Greg Weeks <greg.weeks@timesys.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: Floating point performance
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
In-Reply-To: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Sep 2005 11:29:14.0406 (UTC) FILETIME=[053A5460:01C5C4E9]
Return-Path: <greg.weeks@timesys.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9074
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: greg.weeks@timesys.com
Precedence: bulk
X-list: linux-mips
Content-Length: 943
Lines: 27

Ulrich Eckhardt wrote:

>(Sorry if this mail is garbled, I'm forced to use a sub-par client)
>
>Matej Kupljen wrote:
>  
>
>>I've built soft float toolchain (with crosstool) and then build
>>MPlayer with it. The performance is very low. I cannot even play the
>>mp3 file with MPlayer on DBAU1200 with 400MHz CPU!
>>    
>>
>[...]
>  
>
>>Any other suggestions?
>>    
>>
>
>I'm not sure what you are doing, but if you only want to play music, I'd use Ogg Vorbis instead, which has a decoder that only uses integer arithmetic for exactly the case of FPU-less machines and the Au1200. I could also imagine an MP3 decoder written for integer only being written somewhere, but I don't know anything about it.
>  
>
mpg123 had a version of the libs for OS-9 that used integer ops only. It 
was in contributions and not the mainline and I don't know how difficult 
it would be to get it running on Linux. It's a dead project now anyway.

Greg Weeks

From nigel@mips.com Thu Sep 29 12:40:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 12:40:40 +0100 (BST)
Received: from alg145.algor.co.uk ([62.254.210.145]:31751 "EHLO
	dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S8133641AbVI2LkU
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 12:40:20 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1EKwge-0007Iv-00; Thu, 29 Sep 2005 12:34:52 +0100
Received: from wapping.algor.co.uk ([172.20.192.98])
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1EKwhv-0006ZB-00; Thu, 29 Sep 2005 12:36:11 +0100
Message-ID: <433BD1AA.9060404@mips.com>
Date:	Thu, 29 Sep 2005 12:36:10 +0100
From:	Nigel Stephens <nigel@mips.com>
Organization: MIPS Technologies
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	Ulrich Eckhardt <Eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
Subject: Re: Floating point performance
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local> <1127992600.10179.19.camel@localhost.localdomain>
In-Reply-To: <1127992600.10179.19.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.771,
	required 4, AWL, BAYES_00)
Return-Path: <nigel@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9075
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nigel@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 362
Lines: 16



Matej Kupljen wrote:

>I thought that SF *should* be relatively fast, because I have
>experience with it on ARM, where Nicolas Pitre wrote amazing 
>SF support for the glibc.
>How can we speed-up SF on MIPS? 
>Does anybody have some suggestions?
>  
>

Maybe someone should volunteer to port Nicolas's "amazing SF support" 
from ARM to MIPS. Hint hint.

Nigel

From matej.kupljen@ultra.si Thu Sep 29 12:45:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 12:46:17 +0100 (BST)
Received: from deliver-1.mx.triera.net ([213.161.0.31]:28395 "HELO
	deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP
	id S8133635AbVI2Lp5 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 12:45:57 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id A529AC087;
	Thu, 29 Sep 2005 13:45:31 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id 1C7AB1BC086;
	Thu, 29 Sep 2005 13:45:34 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id 61F111A18B1;
	Thu, 29 Sep 2005 13:45:34 +0200 (CEST)
Subject: Re: Floating point performance
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	Nigel Stephens <nigel@mips.com>
Cc:	Ulrich Eckhardt <Eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
In-Reply-To: <433BD1AA.9060404@mips.com>
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
	 <1127992600.10179.19.camel@localhost.localdomain>
	 <433BD1AA.9060404@mips.com>
Content-Type: text/plain
Date:	Thu, 29 Sep 2005 13:44:49 +0200
Message-Id: <1127994289.10179.20.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9076
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 228
Lines: 11

Hi

> Maybe someone should volunteer to port Nicolas's "amazing SF support" 
> from ARM to MIPS. Hint hint.

It is very ARM specific, so I don't know if it would be possible.
I'll look into it, when I find the time.

BR,
Matej


From matej.kupljen@ultra.si Thu Sep 29 12:50:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 12:50:27 +0100 (BST)
Received: from deliver-1.mx.triera.net ([213.161.0.31]:60395 "HELO
	deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP
	id S8133635AbVI2LuI (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 12:50:08 +0100
Received: from localhost (in-1.mx.triera.net [213.161.0.25])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 15D20C08F;
	Thu, 29 Sep 2005 13:50:02 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-1.mx.triera.net (Postfix) with SMTP id 20EE01BC08B;
	Thu, 29 Sep 2005 13:50:05 +0200 (CEST)
Received: from [172.18.1.53] (unknown [213.161.20.162])
	by smtp.triera.net (Postfix) with ESMTP id D48CE1A18B2;
	Thu, 29 Sep 2005 13:50:04 +0200 (CEST)
Subject: Re: Floating point performance
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	Nigel Stephens <nigel@mips.com>
Cc:	Ulrich Eckhardt <Eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
In-Reply-To: <433BD1AA.9060404@mips.com>
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local>
	 <1127992600.10179.19.camel@localhost.localdomain>
	 <433BD1AA.9060404@mips.com>
Content-Type: text/plain
Date:	Thu, 29 Sep 2005 13:49:20 +0200
Message-Id: <1127994560.10179.22.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9077
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: matej.kupljen@ultra.si
Precedence: bulk
X-list: linux-mips
Content-Length: 300
Lines: 12

Hi

> Maybe someone should volunteer to port Nicolas's "amazing SF support" 
> from ARM to MIPS. Hint hint.

Take a look at those benchmarks:
http://lists.arm.linux.org.uk/pipermail/linux-arm/2004-March/007214.html
http://lists.arm.linux.org.uk/pipermail/linux-arm/2004-March/007223.html

BR,
Matej


From yallain@avilinks.com Thu Sep 29 13:11:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 13:11:32 +0100 (BST)
Received: from paris5.amen.fr ([62.193.203.10]:30471 "EHLO paris5.amen.fr")
	by ftp.linux-mips.org with ESMTP id S8133635AbVI2MLO (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 29 Sep 2005 13:11:14 +0100
Received: from firewall (LAubervilliers-151-13-113-26.w217-128.abo.wanadoo.fr [217.128.183.26])
	by paris5.amen.fr (8.10.2/8.10.2) with ESMTP id j8TCAoq23724;
	Thu, 29 Sep 2005 14:11:00 +0200
Message-ID: <433BD945.8030803@avilinks.com>
Date:	Thu, 29 Sep 2005 14:08:37 +0200
From:	Yoann Allain <yallain@avilinks.com>
Organization: Avilinks
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: fr, en
MIME-Version: 1.0
To:	Brett Foster <fosterb@uoguelph.ca>
CC:	linux-mips@linux-mips.org
Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_Compiling_a_2=2E6_kern?=
 =?ISO-8859-1?Q?el_for_Mips?=
References: <OF6AB06D9F.A4F86C60-ONC125708A.003730C5-C125708A.00479A09@sagem.com> <433A9CD9.6040906@avilinks.com> <433B87CE.1060509@uoguelph.ca>
In-Reply-To: <433B87CE.1060509@uoguelph.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Return-Path: <yallain@avilinks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9078
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yallain@avilinks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3692
Lines: 89

Thank you for your advices! I found the solution: A serial port data 
structure for my card was defined BUT not used in 
include/asm-mips/serial.h to define SERIAL_PORT_DFNS so that the 
structure was emtpy. Now my kernel prints output and goes a little 
further. It doesn't fully work but for first I'll try to fix it on my own...

Thank you all again for your advices...

@+ Yoann

Brett Foster a écrit :

> Yoann Allain wrote:
>
>> Here is the function putPromChar in which I have the problem:
>>
>> 80101e70 <putPromChar>:
>> 80101e70:       3c028039        lui     $v0,0x8039
>> 80101e74:       244519f0        addiu   $a1,$v0,6640
>> 80101e78:       8ca30014        lw      $v1,20($a1)
>> 80101e7c:       00042600        sll     $a0,$a0,24
>> 80101e80:       27bdfff0        addiu   $sp,$sp,-16
>> 80101e84:       00043603        sra     $a2,$a0,24
>> 80101e88:       10600012        beqz    $v1,80101ed4 <putPromChar+0x64>
>> 80101e8c:       00001025        move    $v0,$zero
>> 80101e90:       8ca20004        lw      $v0,4($a1)
>> 80101e94:       3c038036        lui     $v1,0x8036
>> 80101e98:       8c64c9a0        lw      $a0,-13920($v1)
>> 80101e9c:       2442001c        addiu   $v0,$v0,28
>> 80101ea0:       00822021        addu    $a0,$a0,$v0
>> 80101ea4:       00000000        nop
>> 80101ea8:       8c820000        lw      $v0,0($a0)
>> 80101eac:       30420020        andi    $v0,$v0,0x20
>> 80101eb0:       1040fffd        beqz    $v0,80101ea8 <putPromChar+0x38>
>> 80101eb4:       3c028039        lui     $v0,0x8039
>> 80101eb8:       8c4319f4        lw      $v1,6644($v0)
>> 80101ebc:       3c048036        lui     $a0,0x8036
>> 80101ec0:       8c82c9a0        lw      $v0,-13920($a0)
>> 80101ec4:       24630004        addiu   $v1,$v1,4
>> 80101ec8:       00431021        addu    $v0,$v0,$v1
>> 80101ecc:       ac460000        sw      $a2,0($v0)
>> 80101ed0:       24020001        li      $v0,1
>> 80101ed4:       03e00008        jr      $ra
>> 80101ed8:       27bd0010        addiu   $sp,$sp,16
>> 80101edc:       00000000        nop
>>
>> with WinMon (bootloader) I get this (this is perhaps more readable...):
>>
>> [80101e70] 3c028039 lui         r2,0x8039        putPromChar
>> [80101e74] 244519f0 addiu       r5,r2,0x19f0
>> [80101e78] 8ca30014 lw          r3,0x0014(r5)
>> [80101e7c] 00042600 sll         r4,r4,24
>> [80101e80] 27bdfff0 addiu       r29,r29,0xfff0
>> [80101e84] 00043603 sra         r6,r4,24
>> [80101e88] 10600012 beq         r3,r0,0x0012
>> [80101e90] 8ca20004 lw          r2,0x0004(r5)           --> in 2.6 it 
>> reads 0 at address r5 + 0x4  [80101e94] 3c038036 lui         r3,0x8036
>> [80101e98] 8c64c9a0 lw          r4,0xc9a0(r3)        --> in 2.6 it 
>> reads 0 at adress r3 + 0xc9a0
>> [80101e9c] 2442001c addiu       r2,r2,0x001c
>> [80101ea0] 00822021 addu        r4,r4,r2        ==> in 2.4 it returns 
>> bf010f1c in r4
>> [80101ea8] 8c820000 lw          r2,0x0000(r4)
>>
>> * Exception 0x02 (user) : TLB (load or instruction fetch) *
>> * in address: 80101ea8
>> ClockDiv2+0xe38:
>> [80101ea8] 8c820000 lw          r2,0x0000(r4)
>>
>>
>> r0(zero): 00000000 r1(AT)  : 1000fc00 r2(v0)  : 0000001c r3(v1)  : 
>> 80360000
>> r4(a0)  : 0000001c r5(a1)  : 803919f0 r6(a2)  : 0000000d r7(a3)  : 
>> 8038df8c
>>
>> I hope this will help and many thanks for your help!
>>
>> Yoann
>
>
> I traced through some of put character function this morning... I 
> didn't finish, but I thought it looked like some data structure wasn't 
> initialized. Perhaps you can figure out exactly what line the bad load 
> belongs to in the C source, and see what structure that is. -- If 
> there is a data structure -- I could just be crazy. ;)
>
> Brett
>
>

From aravindforl@yahoo.co.in Thu Sep 29 13:52:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 13:53:18 +0100 (BST)
Received: from web35402.mail.mud.yahoo.com ([66.163.179.111]:38491 "HELO
	web35402.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP
	id S8133635AbVI2Mw6 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 13:52:58 +0100
Received: (qmail 46025 invoked by uid 60001); 29 Sep 2005 12:52:51 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.co.in;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=lzoFpo66A0CqAwmKFL10T8T3o09kcdp1fIPF7ztPjARGT2wEIBn+HmQLHn1b/fqkCB59F8fjoumTvRd2+7ROR6RyLjUnaMbBo39+C5Odji00yGagMKxU4cTS1Fs1Fp61PISxKrHxSpJ1WuT+od4GoTQZZSR7aUEp/kYv2ZxcaI8=  ;
Message-ID: <20050929125251.46023.qmail@web35402.mail.mud.yahoo.com>
Received: from [147.243.216.4] by web35402.mail.mud.yahoo.com via HTTP; Thu, 29 Sep 2005 13:52:51 BST
Date:	Thu, 29 Sep 2005 13:52:51 +0100 (BST)
From:	Arravind babu <aravindforl@yahoo.co.in>
Subject: Problem in detecting RAM size by bootloader
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <aravindforl@yahoo.co.in>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9079
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aravindforl@yahoo.co.in
Precedence: bulk
X-list: linux-mips
Content-Length: 406
Lines: 18

Hi all,



         We are using PMON bootloader on MIPS based
board.Earlier we have 64MB of RAM.Now we upgraded to
128MB RAM.But bootloader is not detecting as 128MB.It
is giving 64MB only.Where i have to look to resolve
this issue?


Thanks in advance,
Aravind.


		
__________________________________________________________ 
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com

From drow@nevyn.them.org Thu Sep 29 14:31:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 14:31:46 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:32747 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S8133437AbVI2Nba (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Thu, 29 Sep 2005 14:31:30 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1EKyVR-0001s8-D1; Thu, 29 Sep 2005 09:31:25 -0400
Date:	Thu, 29 Sep 2005 09:31:25 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Nigel Stephens <nigel@mips.com>
Cc:	Matej Kupljen <matej.kupljen@ultra.si>,
	Ulrich Eckhardt <Eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
Subject: Re: Floating point performance
Message-ID: <20050929133124.GA7135@nevyn.them.org>
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local> <1127992600.10179.19.camel@localhost.localdomain> <433BD1AA.9060404@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <433BD1AA.9060404@mips.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9080
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 854
Lines: 27

On Thu, Sep 29, 2005 at 12:36:10PM +0100, Nigel Stephens wrote:
> 
> 
> Matej Kupljen wrote:
> 
> >I thought that SF *should* be relatively fast, because I have
> >experience with it on ARM, where Nicolas Pitre wrote amazing 
> >SF support for the glibc.
> >How can we speed-up SF on MIPS? 
> >Does anybody have some suggestions?
> > 
> >
> 
> Maybe someone should volunteer to port Nicolas's "amazing SF support" 
> from ARM to MIPS. Hint hint.

Unless you've got a spare ASE lying around with conditional execution
and a barrel shifter, I don't think this is in the cards.

Which isn't to say that someone couldn't write a good MIPS-specific
implementation, if they were a sufficiently good FP guru.  But
my feeling is that ARM is more prone than MIPS to clever tricks that
are hard for a compiler to generate.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From ddaney@avtrex.com Thu Sep 29 16:39:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 16:39:51 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:22798
	"EHLO avtrex.com") by ftp.linux-mips.org with ESMTP
	id S8133621AbVI2PjV (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 16:39:21 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 29 Sep 2005 08:39:19 -0700
Message-ID: <433C0AA6.6080500@avtrex.com>
Date:	Thu, 29 Sep 2005 08:39:18 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Matej Kupljen <matej.kupljen@ultra.si>
CC:	Ulrich Eckhardt <Eckhardt@satorlaser.com>,
	linux-mips@linux-mips.org
Subject: Re: Floating point performance
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local> <1127992600.10179.19.camel@localhost.localdomain>
In-Reply-To: <1127992600.10179.19.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Sep 2005 15:39:19.0075 (UTC) FILETIME=[F4B51F30:01C5C50B]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9081
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1884
Lines: 47

Matej Kupljen wrote:
> Hi
> 
> 
>>>I've built soft float toolchain (with crosstool) and then build
>>>MPlayer with it. The performance is very low. I cannot even play the
>>>mp3 file with MPlayer on DBAU1200 with 400MHz CPU!
>>
>>[...]
>>
>>>Any other suggestions?
>>
>>I'm not sure what you are doing, but if you only want to play music, 
>>I'd use Ogg Vorbis instead, which has a decoder that only uses integer 
>>arithmetic for exactly the case of FPU-less machines and the Au1200. 
>>I could also imagine an MP3 decoder written for integer only being 
>>written somewhere, but I don't know anything about it.
> 
> 
> Yes, I can use madplay (libmad) for music only, which uses int
> arithmetics (also special version for MIPS).
> 
> But I also want to play video and currently I am testing this with
> MPlayer (maybe I'll add support for MAE, sometime in the future).
> Then I found out, that MPlayer can use libmad for MP3 and it
> works great know.
> 

We are using libmad and can play 128kbps MP3s on a mips 300MHz 4kc code 
with about 10-15% CPU utilization.

However I think anything but very low resolution low frame rate video is 
out of the question.  You need several orders of magnitude more 
processing power to make it work.  All of the MIPS based video systems 
that I am aware of (TiVo, Sony and Samsung HDTVs etc.) have dedicated 
hardware video decoders.  There are people talking about doing the 
decoding purely in software, but they would be using something with the 
processing power of a 2GHz Pentium4 with special DSP extensions.  As far 
as I know these are just paper designs and are not yet in production.

I guess what I am trying to say is that even if you could make the soft 
float library four times faster, you would still be no where close to 
being able to decode video.

I declare it impossible, but encourage you to prove me wrong.

David Daney.

From ddaney@avtrex.com Thu Sep 29 16:43:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 29 Sep 2005 16:44:01 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([67.116.42.147]:52509
	"EHLO avtrex.com") by ftp.linux-mips.org with ESMTP
	id S8133641AbVI2Pnn (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Thu, 29 Sep 2005 16:43:43 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 29 Sep 2005 08:43:41 -0700
Message-ID: <433C0BAD.5040804@avtrex.com>
Date:	Thu, 29 Sep 2005 08:43:41 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Arravind babu <aravindforl@yahoo.co.in>
CC:	linux-mips@linux-mips.org
Subject: Re: Problem in detecting RAM size by bootloader
References: <20050929125251.46023.qmail@web35402.mail.mud.yahoo.com>
In-Reply-To: <20050929125251.46023.qmail@web35402.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Sep 2005 15:43:41.0713 (UTC) FILETIME=[91408010:01C5C50C]
Return-Path: <ddaney@avtrex.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9082
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 544
Lines: 20

Arravind babu wrote:
> Hi all,
> 
> 
> 
>          We are using PMON bootloader on MIPS based
> board.Earlier we have 64MB of RAM.Now we upgraded to
> 128MB RAM.But bootloader is not detecting as 128MB.It
> is giving 64MB only.Where i have to look to resolve
> this issue?
> 

I would look at the boot monitor source code.  On some systems (Xilleon 
for example) the memory configuration is hardcoded.  In this case, if 
you change the physical memory configuration, you have to make a 
corresponding change to the boot monitor.

David Daney



From anemo@mba.ocn.ne.jp Fri Sep 30 04:32:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 04:33:18 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:8474 "HELO
	topsns.toshiba-tops.co.jp") by ftp.linux-mips.org with SMTP
	id S8133675AbVI3Dcs (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 04:32:48 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 30 Sep 2005 03:32:46 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 88DFF1F693;
	Fri, 30 Sep 2005 12:32:42 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7418B1F569;
	Fri, 30 Sep 2005 12:32:42 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j8U3Wgoj024609;
	Fri, 30 Sep 2005 12:32:42 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Fri, 30 Sep 2005 12:32:41 +0900 (JST)
Message-Id: <20050930.123241.72709288.nemoto@toshiba-tops.co.jp>
To:	linux-mips@linux-mips.org
Cc:	ralf@linux-mips.org
Subject: Re: missing data cache flush for signal trampoline on fork
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050928.205758.32501424.nemoto@toshiba-tops.co.jp>
References: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp>
	<20050928.205758.32501424.nemoto@toshiba-tops.co.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9083
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1593
Lines: 39

>>>>> On Wed, 28 Sep 2005 20:57:58 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
anemo> Sorry, this would corrupt cpu_has_ic_fills_f_dc case.  Revised.

The patch was overkill.  The indexed-flush is required only for
d-cache.  Revised.

diff -u linux-mips/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-mips/arch/mips/mm/c-r4k.c	2005-09-22 10:38:23.000000000 +0900
+++ linux/arch/mips/mm/c-r4k.c	2005-09-30 12:25:14.000000000 +0900
@@ -410,7 +410,11 @@
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
 	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || (exec && !cpu_has_ic_fills_f_dc)) {
+		if (exec && !cpu_has_ic_fills_f_dc) {
+			r4k_blast_dcache_page_indexed(page);
+			if (!cpu_icache_snoops_remote_store)
+				r4k_blast_scache_page_indexed(page);
+		} else if (cpu_has_dc_aliases) {
 			r4k_blast_dcache_page(page);
 			if (exec && !cpu_icache_snoops_remote_store)
 				r4k_blast_scache_page(page);
diff -u linux-mips/arch/mips/mm/c-tx39.c linux/arch/mips/mm/c-tx39.c
--- linux-mips/arch/mips/mm/c-tx39.c	2005-09-05 10:16:59.000000000 +0900
+++ linux/arch/mips/mm/c-tx39.c	2005-09-30 12:26:23.000000000 +0900
@@ -214,7 +214,9 @@
 	 * in that case, which doesn't overly flush the cache too much.
 	 */
 	if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID)) {
-		if (cpu_has_dc_aliases || exec)
+		if (exec)
+			tx39_blast_dcache_page_indexed(page);
+		else if (cpu_has_dc_aliases)
 			tx39_blast_dcache_page(page);
 		if (exec)
 			tx39_blast_icache_page(page);

---
Atsushi Nemoto

From redhatter@gentoo.org Fri Sep 30 06:56:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 06:56:27 +0100 (BST)
Received: from 202-47-55-78.adsl.gil.com.au ([202.47.55.78]:46314 "EHLO
	longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP
	id S8133684AbVI3F4G (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 06:56:06 +0100
Received: (qmail 22053 invoked by uid 210); 30 Sep 2005 15:55:54 +1000
Received: from 10.0.0.251 by www (envelope-from <redhatter@gentoo.org>, uid 201) with qmail-scanner-1.25st 
 (spamassassin: 3.0.4. perlscan: 1.25st.  
 Clear:RC:1(10.0.0.251):. 
 Processed in 0.098293 secs); 30 Sep 2005 05:55:54 -0000
Received: from beast.redhatters.home (HELO ?10.0.0.251?) (10.0.0.251)
  by 192.168.5.1 with SMTP; 30 Sep 2005 15:55:54 +1000
Message-ID: <433CD36E.7040807@gentoo.org>
Date:	Fri, 30 Sep 2005 15:55:58 +1000
From:	Stuart Longland <redhatter@gentoo.org>
Organization: Gentoo Foundation
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	oski <oski2001@hotmail.com>
CC:	linux-mips@linux-mips.org
Subject: Re: Compiling a kernel for ibm z50
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl> <20050928183731.GA18480@linux-mips.org>
In-Reply-To: <20050928183731.GA18480@linux-mips.org>
X-Enigmail-Version: 0.91.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="------------enig2C16DC01A01881EB550A5D20"
Return-Path: <redhatter@gentoo.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9084
X-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
Content-Length: 2244
Lines: 58

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2C16DC01A01881EB550A5D20
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Ralf Baechle wrote:
> On Tue, Sep 27, 2005 at 06:19:51PM +0100, oski wrote:
> 
> 
>>This is my set up:
>>-An old Pentium II box with Redhat 8
>>-Downloaded linux-2.6.13.mipscvs-20050904 from www.longlandclan...and bzip2
>>and tar into /usr/src.
>>-Installed the mipsel crosscompiler from MIPS SDE
>>-After make config, when trying to make dep, I get a warning: make dep is
>>unnecessary now.
>>-Doing a ls arch/mips/boot I get a file called "compressed" with only a
>>folder called "CVS" .
> 
> 
> That's because who made that tarball didn't know his way around CVS enough
> to supply a -P option.  Nothing to worry, just extra clutter.
> 
>   Ralf

Heh, I've never had to use -P.  Hence my script[1] doesn't use -P.  Mind
you, I'll possibly end up porting that script to use git, once I get git
figured out (and the repository dragged across the web... good thing the
month's quota is almost up).

Incidentally, you do realise that you don't `make bzImage` like you do
under x86 don't you?  On mips, we use the raw vmlinux file (or
sometimes, we `make vmlinux.32`).  This is fed to the bootloader.
-- 
 ____                   _             Stuart Longland (a.k.a Redhatter)
/  _ \   ___    ___  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \                        Developer
 \    //  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \____/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter
1.
http://www.longlandclan.hopto.org/~stuartl/mips-linux/utilities/get_kernel.sh.gz

--------------enig2C16DC01A01881EB550A5D20
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.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFDPNNxuarJ1mMmSrkRArGeAJ91Iy+wBYJ/x0NbQiD7bBe5TGNF8ACXeffj
rI00wKova7h8JcDlkSS5Aw==
=t4B2
-----END PGP SIGNATURE-----

--------------enig2C16DC01A01881EB550A5D20--

From ralf@linux-mips.org Fri Sep 30 11:42:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:42:44 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:31002 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465566AbVI3Km2 (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:28 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLue005536;
	Fri, 30 Sep 2005 11:42:22 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8U0q5E4016524;
	Fri, 30 Sep 2005 01:52:05 +0100
Date:	Fri, 30 Sep 2005 01:52:05 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Christoph Hellwig <hch@lst.de>
Cc:	akpm@osdl.org, linux-mips@linux-mips.org
Subject: Re: [PATCH] switch sibyte profiling driver to ->compat_ioctl
Message-ID: <20050930005205.GH3983@linux-mips.org>
References: <20050919150822.GB13478@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050919150822.GB13478@lst.de>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9085
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 93
Lines: 5

On Mon, Sep 19, 2005 at 05:08:22PM +0200, Christoph Hellwig wrote:

Thanks, applied.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:43:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:43:38 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:60441 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465567AbVI3Kma (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:30 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLug005536;
	Fri, 30 Sep 2005 11:42:24 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8TNwVFG004635;
	Fri, 30 Sep 2005 00:58:31 +0100
Date:	Fri, 30 Sep 2005 00:58:31 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: add __iomem to ioremap
Message-ID: <20050929235831.GD3983@linux-mips.org>
References: <20050926.001753.74752084.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050926.001753.74752084.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9086
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 296
Lines: 9

On Mon, Sep 26, 2005 at 12:17:53AM +0900, Atsushi Nemoto wrote:

> Some function like iounmap, read[bwlq], etc. have been using __iomem
> attribute, but ioremap does not use it.  Here is a patch to add
> __iomem to ioremap family.  This would kill some sparse warnings.

Thanks, applied.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:44:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:44:28 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:44308 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465568AbVI3Kmc (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:32 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLuc005536;
	Fri, 30 Sep 2005 11:42:21 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8U8dAW2024366;
	Fri, 30 Sep 2005 09:39:10 +0100
Date:	Fri, 30 Sep 2005 09:39:10 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	oski <oski2001@hotmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Compiling a kernel for ibm z50
Message-ID: <20050930083910.GI3983@linux-mips.org>
References: <BAY101-DAV76EF721B0CFCE85875AC3D28A0@phx.gbl> <20050928183731.GA18480@linux-mips.org> <BAY101-DAV183674DFDB1AD65FC8FF36D28C0@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAY101-DAV183674DFDB1AD65FC8FF36D28C0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9087
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 831
Lines: 23

On Thu, Sep 29, 2005 at 01:21:43PM +0100, oski wrote:

> After config I run make and got an error.
> The last few lines are
> LD    init/built-in.o
> LD    .tmp_vmlinux1
> drivers/built-in.o: in function 'pnp_check_dma':
> : undefined reference to :'request_dma'
> drivers/built-in.o: in function 'pnp_check_dma':
> : relocation truncated to fit: R_MIPS_26 against 'request_dma'
> drivers/built-in.o: In function 'pnp_check_dma':
> : undefined reference to 'free_dma'
> drivers/built-in.o: In function 'pnp_check_dma':
> : relocation truncated to fit: R_MIPS_26 against 'free_dma'
> make: *** [.tmp_vmlinux1] Error 1
> 
> Any suggestions how can I solve this error problem and progressing in
> building the kernel?

Disable CONFIG_PNP; I don't think that option makes sense on a Z50 but
Yoichi may want to correct me here.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:44:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:45:22 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:39947 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465569AbVI3Kmf (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLuk005536;
	Fri, 30 Sep 2005 11:42:27 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8U0Dnq7004716;
	Fri, 30 Sep 2005 01:13:49 +0100
Date:	Fri, 30 Sep 2005 01:13:49 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] Revise MIPS64 ptrace interface
Message-ID: <20050930001349.GF3983@linux-mips.org>
References: <20050922182601.GA10829@nevyn.them.org> <20050928221115.GA22817@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050928221115.GA22817@nevyn.them.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9088
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 698
Lines: 18

On Wed, Sep 28, 2005 at 06:11:15PM -0400, Daniel Jacobowitz wrote:

> Change the N32 debugging ABI to something more sane, and add support
> for o32 and n32 debuggers to trace n64 programs.
> 
> Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
> ---
> 
> I've now tested everything except the actual _3264 operations, which
> were copied from PPC anyway and I have reasonable faith in.  So here's
> a final patch.  If this seems reasonable to everyone, I'd like for it
> to be merged, and then I can submit the glibc and gdb bits.

I haven't heared any objections and I guess for an interface like ptrace
such a somewhat trigger happy change is still ok, so I've applied your
patch.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:45:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:46:09 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:47642 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465570AbVI3Kmf (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLui005536;
	Fri, 30 Sep 2005 11:42:27 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8U05onK004667;
	Fri, 30 Sep 2005 01:05:50 +0100
Date:	Fri, 30 Sep 2005 01:05:50 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: RFC: Revise n32 ptrace interface
Message-ID: <20050930000550.GE3983@linux-mips.org>
References: <20050922182601.GA10829@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050922182601.GA10829@nevyn.them.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9089
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 571
Lines: 12

On Thu, Sep 22, 2005 at 02:26:01PM -0400, Daniel Jacobowitz wrote:

> 1.  We need to get at the 64-bit registers.  I considered a number of
> different approaches for this and decided to just implement a 64-bit
> PTRACE_GETREGS instead of messing with PTRACE_PEEKUSR.  It's much simpler
> this way.  I didn't add one for the DSP registers; that can be handled
> separately when someone's working on debug support for them...

I quite deliberately did omit DSP support from 64-bit ptrace(2); there
is currently no MIPS64 processor with DSP support that I know of.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:46:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:47:02 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:50952 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465571AbVI3Kmg (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:36 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLus005536;
	Fri, 30 Sep 2005 11:42:30 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8TNUxd5004328;
	Fri, 30 Sep 2005 00:30:59 +0100
Date:	Fri, 30 Sep 2005 00:30:58 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: sync c-tx39.c with c-r4k.c
Message-ID: <20050929233058.GA3983@linux-mips.org>
References: <20050928.202458.32344678.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050928.202458.32344678.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9090
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 597
Lines: 17

On Wed, Sep 28, 2005 at 08:24:58PM +0900, Atsushi Nemoto wrote:

> tx39_flush_cache_range() do nothing if !cpu_has_dc_aliases.  It should
> flush d-cache and invalidate i-cache since TX39(H2) has separate I/D
> cache.

Thanks, applied.

If you and other patch submitters would in the future please also start
sending patches with Signed-off-by: lines, for more please see
Documentation/SubmittingPatches.

In the past I didn't bother because we ended up blending all patches in
the CVS archive anyway to the point where they just didn't make sense
anymore.  Now with git that has changed.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:47:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:47:56 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:41990 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465572AbVI3Kmg (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:36 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLuo005536;
	Fri, 30 Sep 2005 11:42:27 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8TNjhOi004468;
	Fri, 30 Sep 2005 00:45:43 +0100
Date:	Fri, 30 Sep 2005 00:45:42 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Message-ID: <20050929234542.GB3983@linux-mips.org>
References: <cda58cb8050926000665f843dc@mail.gmail.com> <20050926115539.GB3175@linux-mips.org> <cda58cb805092605057f7cad7d@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb805092605057f7cad7d@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9091
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 917
Lines: 30

On Mon, Sep 26, 2005 at 02:05:36PM +0200, Franck wrote:

> 2005/9/26, Ralf Baechle <ralf@linux-mips.org>:
> > On Mon, Sep 26, 2005 at 09:06:50AM +0200, Franck wrote:
> >
> > > This patch replaces an empty preprocessor condition #elif by #else.

Thanks for noticing.

> > > It adds 4ksc and 4ksd as well.

--- module.h~old        2005-09-26 14:02:32.000000000 +0200
+++ module.h    2005-09-26 09:54:08.000000000 +0200
@@ -113,7 +113,11 @@ search_module_dbetables(unsigned long ad
 #define MODULE_PROC_FAMILY "RM9000"
 #elif defined CONFIG_CPU_SB1
 #define MODULE_PROC_FAMILY "SB1"
-#elif
+#elif defined CONFIG_CPU_4KSC
+#define MODULE_PROC_FAMILY "4KSC"
+#elif defined CONFIG_CPU_4KSD
+#define MODULE_PROC_FAMILY "4KSD"

There are no CONFIG_CPU_4KSC and CONFIG_CPU_4KSD configuration options.
Did you really create this patch against the linux module of the CVS
repository or was it a different tree?

Thanks,

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:48:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:48:47 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:8202 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465573AbVI3Kmg (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:36 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLum005536;
	Fri, 30 Sep 2005 11:42:27 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8TNoPB4004496;
	Fri, 30 Sep 2005 00:50:25 +0100
Date:	Fri, 30 Sep 2005 00:50:25 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Message-ID: <20050929235025.GC3983@linux-mips.org>
References: <cda58cb80509260216591eb96b@mail.gmail.com> <20050926122114.GC3175@linux-mips.org> <cda58cb80509260546a6f4118@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb80509260546a6f4118@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9092
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 850
Lines: 18

On Mon, Sep 26, 2005 at 02:46:02PM +0200, Franck wrote:

> > IP27 currently the only system that absolutely needs discontiguous
> > memory in order to work at all.  A few other systems could make use of
> > discontiguous memory to reduce the waste of memory - the family of
> > Broadcom SB1 based systems comes to mind.
> 
> Isn't discontiguous memory common for embedded system as well ? I
> thought so...Anyways can we make discontiguous memory thing move into
> generic MIPS code so every future needs for that will profit ? I
> looked at other arch, and they seem to implement it that way (in
> arch/xxx/mm/discontig.c).

Yes, that would be a good thing.  There are several platforms that could
make good use of discontiguous memory support such as Broadcom's Sibyte
SoCs with their insanely large hole in the memory map but also others.

  Ralf

From ralf@linux-mips.org Fri Sep 30 11:49:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 11:49:41 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:20758 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465574AbVI3Kmh (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 11:42:37 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UAgLuq005536;
	Fri, 30 Sep 2005 11:42:30 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8U0KHHV004732;
	Fri, 30 Sep 2005 01:20:17 +0100
Date:	Fri, 30 Sep 2005 01:20:17 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Jan Pedersen <jan.pedersen@glaze.dk>
Cc:	linux-mips@linux-mips.org
Subject: Re: [patch] cfi: prevent kernel panic with cfi flash
Message-ID: <20050930002017.GG3983@linux-mips.org>
References: <20050927192543.CAD8F376451@rocket.glaze.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050927192543.CAD8F376451@rocket.glaze.se>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9093
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1023
Lines: 26

On Tue, Sep 27, 2005 at 09:25:42PM +0200, Jan Pedersen wrote:

> When using the cfi (common flash interface) driver, every word written to
> the flash chips is followed by a operation complete poll. This poll is
> intended to have a timeout of 1 ms. However this timeout is calculated by
> HZ/1000, which happends to be 0 because HZ < 1000. The result of this is
> that there will be just one poll for operation complete. If this single poll
> fails, the kernel panics. This patch increases this timeout to HZ (1
> second). This is far more than needed, but is preferred over a panic. This
> fix is well tested and completely avoids the panic.
> 
> Signed-off-by: Jan Pedersen <jp@jp-embedded.com>

Patch looks good to me - but this code isn't maintained by linux-mips.org,
so you may want to resend your patches here:

MEMORY TECHNOLOGY DEVICES
P:      David Woodhouse
M:      dwmw2@infradead.org
W:      http://www.linux-mtd.infradead.org/
L:      linux-mtd@lists.infradead.org
S:      Maintained

Thanks anyway,

  Ralf

From D.Mierzejewski@icm.edu.pl Fri Sep 30 12:48:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 12:48:42 +0100 (BST)
Received: from gw.icm.edu.pl ([212.87.0.39]:55990 "EHLO atol.icm.edu.pl")
	by ftp.linux-mips.org with ESMTP id S3465570AbVI3LsW (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Fri, 30 Sep 2005 12:48:22 +0100
Received: from fs.icm.edu.pl (fs.icm.edu.pl [192.168.1.165])
	by atol.icm.edu.pl (8.13.1/8.13.1/rzm-5.1/icm) with ESMTP id j8UBmIbm020204
	for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 13:48:18 +0200
Received: from ws-gradcol1.icm.edu.pl (ws-gradcol1.icm.edu.pl [192.168.1.26])
	by fs.icm.edu.pl (8.13.3/8.13.2/rzm-5.0hub/icm) with ESMTP id j8UBmIxj015749
	for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 13:48:18 +0200 (CEST)
Received: by ws-gradcol1.icm.edu.pl (Postfix, from userid 5242)
	id 065D1920DA; Fri, 30 Sep 2005 13:48:17 +0200 (CEST)
Date:	Fri, 30 Sep 2005 13:48:16 +0200
From:	"Dominik 'Rathann' Mierzejewski" <D.Mierzejewski@icm.edu.pl>
To:	linux-mips@linux-mips.org
Subject: Re: Floating point performance
Message-ID: <20050930114816.GB13730@ws-gradcol1.icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <6EC3F44BE5E6B742BE3EBC3465525944096814@emea-exchange3.emea.dps.local> <1127992600.10179.19.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1127992600.10179.19.camel@localhost.localdomain>
User-Agent: Mutt/1.5.9i
X-Rcpt-To: <linux-mips@linux-mips.org>
X-Classes: vf: <linux-mips@linux-mips.org>, vh: , sf: <linux-mips@linux-mips.org>, sh:  (MDrzm)
X-Filtry: w sprawie filtracji wirusow i spamu pisz do: spam@icm.edu.pl
X-Scanned-By: MIMEDefang 2.51 on 192.168.1.242
Return-Path: <D.Mierzejewski@icm.edu.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9094
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: D.Mierzejewski@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1679
Lines: 40

On Thu, Sep 29, 2005 at 01:16:40PM +0200, Matej Kupljen wrote:
> Hi
> 
> > > I've built soft float toolchain (with crosstool) and then build
> > > MPlayer with it. The performance is very low. I cannot even play the
> > > mp3 file with MPlayer on DBAU1200 with 400MHz CPU!
> > [...]
> > > Any other suggestions?
> > 
> > I'm not sure what you are doing, but if you only want to play music, 
> > I'd use Ogg Vorbis instead, which has a decoder that only uses integer 
> > arithmetic for exactly the case of FPU-less machines and the Au1200. 
> > I could also imagine an MP3 decoder written for integer only being 
> > written somewhere, but I don't know anything about it.
> 
> Yes, I can use madplay (libmad) for music only, which uses int
> arithmetics (also special version for MIPS).
> 
> But I also want to play video and currently I am testing this with
> MPlayer (maybe I'll add support for MAE, sometime in the future).
> Then I found out, that MPlayer can use libmad for MP3 and it
> works great know.
> 
> Now I'll try to write XV driver for MAE backend so I'll have
> HW accelerated Color Space Conversion (form YV12->RGB) and
> Scaling. 

If you're interested in video playback using MPlayer, you may
want to port the assembly parts of its code to MIPS. We (MPlayer
developers) would be grateful if you could contribute your code
back to MPlayer. I'm sure that you can get assistance from our
coders if you have any problems and questions about the code.

Regards,
R.

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

From vagabon.xyz@gmail.com Fri Sep 30 13:36:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 13:36:28 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.203]:41666 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S3465570AbVI3MgI convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 13:36:08 +0100
Received: by zproxy.gmail.com with SMTP id j2so458644nzf
        for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 05:36:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BbSQQa42LqM9mCY7TueEmSZ69KPJvQiiTz4gFg+0uXL2Z+MAnST4N7PXw7UXj2ilaf+S5lGB3eOJVsdB0loVpGCY1uziQJnhHE37cxRJU/+dg3E6TwPHJLI06qN3F3poNY+hEcGOX/f/oBW3ja1yF5b4bvEPPU1utP1aqx1jo+4=
Received: by 10.37.18.42 with SMTP id v42mr1412730nzi;
        Fri, 30 Sep 2005 05:36:02 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Fri, 30 Sep 2005 05:36:01 -0700 (PDT)
Message-ID: <cda58cb80509300536q42e9ddd4q@mail.gmail.com>
Date:	Fri, 30 Sep 2005 14:36:01 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050929234542.GB3983@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <cda58cb8050926000665f843dc@mail.gmail.com>
	 <20050926115539.GB3175@linux-mips.org>
	 <cda58cb805092605057f7cad7d@mail.gmail.com>
	 <20050929234542.GB3983@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9095
X-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
Content-Length: 492
Lines: 16

Hi Ralf,

2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> There are no CONFIG_CPU_4KSC and CONFIG_CPU_4KSD configuration options.
> Did you really create this patch against the linux module of the CVS
> repository or was it a different tree?
>

The patch was created against linux-mips CVS repository. I added 4KSC
and 4KSD support in this tree. I thougth seeing reference of 4KSC
somewhere. Anyway, if you don't want to include them in your tree
that's ok.

Thanks
--
               Franck

From vagabon.xyz@gmail.com Fri Sep 30 13:40:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 13:40:58 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.196]:5669 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S3465571AbVI3Mki convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 13:40:38 +0100
Received: by zproxy.gmail.com with SMTP id j2so459209nzf
        for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 05:40:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=V4DqR6OaY3zdWju5MZ8RdnIKEoMuN4DK32LkSrPDIadIcceFzpgexUEPltaDGjElQSrXbCtGxtMkY+SBc/cd811WgcBbv37NVXg0R8uUjX1O7hSszEil4DMAe5xNKnJuY1xlFQo1VhuExwpthod3RF3UmE/z0v7n4Ksm665vTtc=
Received: by 10.36.42.2 with SMTP id p2mr6170222nzp;
        Fri, 30 Sep 2005 05:40:31 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Fri, 30 Sep 2005 05:40:31 -0700 (PDT)
Message-ID: <cda58cb80509300540i7a419fb8u@mail.gmail.com>
Date:	Fri, 30 Sep 2005 14:40:31 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050929235025.GC3983@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <cda58cb80509260216591eb96b@mail.gmail.com>
	 <20050926122114.GC3175@linux-mips.org>
	 <cda58cb80509260546a6f4118@mail.gmail.com>
	 <20050929235025.GC3983@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9096
X-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
Content-Length: 1176
Lines: 27

2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> On Mon, Sep 26, 2005 at 02:46:02PM +0200, Franck wrote:
>
> > > IP27 currently the only system that absolutely needs discontiguous
> > > memory in order to work at all.  A few other systems could make use of
> > > discontiguous memory to reduce the waste of memory - the family of
> > > Broadcom SB1 based systems comes to mind.
> >
> > Isn't discontiguous memory common for embedded system as well ? I
> > thought so...Anyways can we make discontiguous memory thing move into
> > generic MIPS code so every future needs for that will profit ? I
> > looked at other arch, and they seem to implement it that way (in
> > arch/xxx/mm/discontig.c).
>
> Yes, that would be a good thing.  There are several platforms that could
> make good use of discontiguous memory support such as Broadcom's Sibyte
> SoCs with their insanely large hole in the memory map but also others.
>

Ok I'll try to do that soon (maybe in 1 or 2 weeks). I looked at the
ARM's code and I should be able to do the same on MIPS. Should I keep
IP27 data structure and code although ARM's ones seem to be easier to
understand ?

Thanks
--
               Franck

From ralf@linux-mips.org Fri Sep 30 14:09:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 14:09:59 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:43542 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465571AbVI3NJj (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 14:09:39 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UD9Th0007271;
	Fri, 30 Sep 2005 14:09:29 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UD9Sqo007270;
	Fri, 30 Sep 2005 14:09:28 +0100
Date:	Fri, 30 Sep 2005 14:09:28 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Message-ID: <20050930130928.GA3083@linux-mips.org>
References: <cda58cb8050926000665f843dc@mail.gmail.com> <20050926115539.GB3175@linux-mips.org> <cda58cb805092605057f7cad7d@mail.gmail.com> <20050929234542.GB3983@linux-mips.org> <cda58cb80509300536q42e9ddd4q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb80509300536q42e9ddd4q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9097
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 760
Lines: 19

On Fri, Sep 30, 2005 at 02:36:01PM +0200, Franck wrote:

> 2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> > There are no CONFIG_CPU_4KSC and CONFIG_CPU_4KSD configuration options.
> > Did you really create this patch against the linux module of the CVS
> > repository or was it a different tree?
> >
> 
> The patch was created against linux-mips CVS repository. I added 4KSC
> and 4KSD support in this tree. I thougth seeing reference of 4KSC
> somewhere. Anyway, if you don't want to include them in your tree
> that's ok.

It's just that references to CONFIG_* symbols that are being defined
nowhere don't make sense.  If however you want to contribute improved
support for these processors, by all means I'm certainly going to appreciate
a patch!

  Ralf

From ralf@linux-mips.org Fri Sep 30 14:49:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 14:49:24 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:63763 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465576AbVI3NtI (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 14:49:08 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UDn0Fk008867;
	Fri, 30 Sep 2005 14:49:00 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UDn0hV008866;
	Fri, 30 Sep 2005 14:49:00 +0100
Date:	Fri, 30 Sep 2005 14:49:00 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Message-ID: <20050930134900.GB3083@linux-mips.org>
References: <cda58cb80509260216591eb96b@mail.gmail.com> <20050926122114.GC3175@linux-mips.org> <cda58cb80509260546a6f4118@mail.gmail.com> <20050929235025.GC3983@linux-mips.org> <cda58cb80509300540i7a419fb8u@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb80509300540i7a419fb8u@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9098
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1425
Lines: 29

On Fri, Sep 30, 2005 at 02:40:31PM +0200, Franck wrote:

> > > > IP27 currently the only system that absolutely needs discontiguous
> > > > memory in order to work at all.  A few other systems could make use of
> > > > discontiguous memory to reduce the waste of memory - the family of
> > > > Broadcom SB1 based systems comes to mind.
> > >
> > > Isn't discontiguous memory common for embedded system as well ? I
> > > thought so...Anyways can we make discontiguous memory thing move into
> > > generic MIPS code so every future needs for that will profit ? I
> > > looked at other arch, and they seem to implement it that way (in
> > > arch/xxx/mm/discontig.c).
> >
> > Yes, that would be a good thing.  There are several platforms that could
> > make good use of discontiguous memory support such as Broadcom's Sibyte
> > SoCs with their insanely large hole in the memory map but also others.
> >
> 
> Ok I'll try to do that soon (maybe in 1 or 2 weeks). I looked at the
> ARM's code and I should be able to do the same on MIPS. Should I keep
> IP27 data structure and code although ARM's ones seem to be easier to
> understand ?

The IP27 code is a little obscure which partly is explained by it's age;
it's been the first NUMA system to be supported in Linux.  After a
quick look the ARM code seems a little to simple to deal with such a
system, so I suggest you take a look at arch/ia64/mm/discontig.c instead.

  Ralf

From ralf@linux-mips.org Fri Sep 30 16:11:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 16:11:27 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:262 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465580AbVI3PLA (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 16:11:00 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UFAsvx012083;
	Fri, 30 Sep 2005 16:10:54 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UFAqTv012082;
	Fri, 30 Sep 2005 16:10:52 +0100
Date:	Fri, 30 Sep 2005 16:10:52 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org
Subject: Re: missing data cache flush for signal trampoline on fork
Message-ID: <20050930151052.GD3083@linux-mips.org>
References: <20050928.203429.02302175.nemoto@toshiba-tops.co.jp> <20050928.205758.32501424.nemoto@toshiba-tops.co.jp> <20050930.123241.72709288.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050930.123241.72709288.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9099
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 868
Lines: 26

On Fri, Sep 30, 2005 at 12:32:41PM +0900, Atsushi Nemoto wrote:
> Date:	Fri, 30 Sep 2005 12:32:41 +0900 (JST)
> To:	linux-mips@linux-mips.org
> Cc:	ralf@linux-mips.org
> Subject: Re: missing data cache flush for signal trampoline on fork
> From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> Content-Type: Text/Plain; charset=us-ascii
> 
> >>>>> On Wed, 28 Sep 2005 20:57:58 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> anemo> Sorry, this would corrupt cpu_has_ic_fills_f_dc case.  Revised.
> 
> The patch was overkill.  The indexed-flush is required only for
> d-cache.  Revised.

Hmm...  Your patch may be right for the time being but I think this should
the whole flushing biz should actually be handled via update_mmu_cache by
adding something along the lines of:

...
	if (vma->flags & VM_EXEC)
		do_flush_icache_page(addr);
...

What do you think?

  Ralf

From vagabon.xyz@gmail.com Fri Sep 30 16:35:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 16:36:11 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.207]:64845 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S3465580AbVI3Pfz convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 16:35:55 +0100
Received: by zproxy.gmail.com with SMTP id j2so487476nzf
        for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 08:35:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AekFcibA/x90ZiSqF2tFxyvKqaaQZ/DuLaeruJ1CmVwRKa/X2lELl0JWhbBhadQOzI7t4sBAye8HBnTnF6jrCJWsjpACixz0yVEIhL6YY4vQ9jR9o2GV+4rqIsgQXd5qXvwOaFfrRPGKTFyOl45jfEBhGCPZ2RakZIZ9kZ6Dyeg=
Received: by 10.37.22.45 with SMTP id z45mr3772750nzi;
        Fri, 30 Sep 2005 08:35:48 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Fri, 30 Sep 2005 08:35:48 -0700 (PDT)
Message-ID: <cda58cb80509300835x5f5ede9fg@mail.gmail.com>
Date:	Fri, 30 Sep 2005 17:35:48 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: DISCONTIGMEM suuport on 32 bits MIPS
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050930134900.GB3083@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <cda58cb80509260216591eb96b@mail.gmail.com>
	 <20050926122114.GC3175@linux-mips.org>
	 <cda58cb80509260546a6f4118@mail.gmail.com>
	 <20050929235025.GC3983@linux-mips.org>
	 <cda58cb80509300540i7a419fb8u@mail.gmail.com>
	 <20050930134900.GB3083@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9100
X-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
Content-Length: 1569
Lines: 35

2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> On Fri, Sep 30, 2005 at 02:40:31PM +0200, Franck wrote:
>
> > > > > IP27 currently the only system that absolutely needs discontiguous
> > > > > memory in order to work at all.  A few other systems could make use of
> > > > > discontiguous memory to reduce the waste of memory - the family of
> > > > > Broadcom SB1 based systems comes to mind.
> > > >
> > > > Isn't discontiguous memory common for embedded system as well ? I
> > > > thought so...Anyways can we make discontiguous memory thing move into
> > > > generic MIPS code so every future needs for that will profit ? I
> > > > looked at other arch, and they seem to implement it that way (in
> > > > arch/xxx/mm/discontig.c).
> > >
> > > Yes, that would be a good thing.  There are several platforms that could
> > > make good use of discontiguous memory support such as Broadcom's Sibyte
> > > SoCs with their insanely large hole in the memory map but also others.
> > >
> >
> > Ok I'll try to do that soon (maybe in 1 or 2 weeks). I looked at the
> > ARM's code and I should be able to do the same on MIPS. Should I keep
> > IP27 data structure and code although ARM's ones seem to be easier to
> > understand ?
>
> The IP27 code is a little obscure which partly is explained by it's age;
> it's been the first NUMA system to be supported in Linux.  After a
> quick look the ARM code seems a little to simple to deal with such a
> system, so I suggest you take a look at arch/ia64/mm/discontig.c instead.
>

Ok, I'll do that.

Thanks
--
               Franck

From vagabon.xyz@gmail.com Fri Sep 30 16:44:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 16:44:27 +0100 (BST)
Received: from zproxy.gmail.com ([64.233.162.206]:11369 "EHLO zproxy.gmail.com")
	by ftp.linux-mips.org with ESMTP id S3465585AbVI3PoI convert rfc822-to-8bit
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 16:44:08 +0100
Received: by zproxy.gmail.com with SMTP id j2so488773nzf
        for <linux-mips@linux-mips.org>; Fri, 30 Sep 2005 08:44:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QTCJk+y/DqJiK/w7zqqkYd2slR5Po+DzYY9j2KKlS+3o18wpEVZiB9dconOZTkUP2NvUOzXvBwUcHNNqw30npj998VC+BB+j72bPVImZ+5JYLeP3IrTx5kvivuwAGY4Wbrh4oXiNjqlC1/ZdSwoYl0BnuYgOO9N4dVWE6cT5Aus=
Received: by 10.36.108.12 with SMTP id g12mr1006961nzc;
        Fri, 30 Sep 2005 08:44:01 -0700 (PDT)
Received: by 10.36.49.3 with HTTP; Fri, 30 Sep 2005 08:44:01 -0700 (PDT)
Message-ID: <cda58cb80509300844v5181d6fey@mail.gmail.com>
Date:	Fri, 30 Sep 2005 17:44:01 +0200
From:	Franck <vagabon.xyz@gmail.com>
Reply-To: Franck <vagabon.xyz@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050930130928.GA3083@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <cda58cb8050926000665f843dc@mail.gmail.com>
	 <20050926115539.GB3175@linux-mips.org>
	 <cda58cb805092605057f7cad7d@mail.gmail.com>
	 <20050929234542.GB3983@linux-mips.org>
	 <cda58cb80509300536q42e9ddd4q@mail.gmail.com>
	 <20050930130928.GA3083@linux-mips.org>
Return-Path: <vagabon.xyz@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9101
X-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
Content-Length: 989
Lines: 26

2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> On Fri, Sep 30, 2005 at 02:36:01PM +0200, Franck wrote:
>
> > 2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> > > There are no CONFIG_CPU_4KSC and CONFIG_CPU_4KSD configuration options.
> > > Did you really create this patch against the linux module of the CVS
> > > repository or was it a different tree?
> > >
> >
> > The patch was created against linux-mips CVS repository. I added 4KSC
> > and 4KSD support in this tree. I thougth seeing reference of 4KSC
> > somewhere. Anyway, if you don't want to include them in your tree
> > that's ok.
>
> It's just that references to CONFIG_* symbols that are being defined
> nowhere don't make sense.  If however you want to contribute improved
> support for these processors, by all means I'm certainly going to appreciate
> a patch!
>

I'm surprised you're interested in added support for 4KSC and 4KSD
cpu...Anyway I could send a trivial patch to you if so.

Thanks
--
               Franck

From ralf@linux-mips.org Fri Sep 30 17:10:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 17:10:20 +0100 (BST)
Received: from extgw-uk.mips.com ([62.254.210.129]:59409 "EHLO
	bacchus.net.dhis.org") by ftp.linux-mips.org with ESMTP
	id S3465585AbVI3QKB (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 17:10:01 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j8UG9rCQ014050;
	Fri, 30 Sep 2005 17:09:53 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j8UG9qfL014049;
	Fri, 30 Sep 2005 17:09:52 +0100
Date:	Fri, 30 Sep 2005 17:09:52 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Franck <vagabon.xyz@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: [PATCH] minor fix in asm-mips/module.h
Message-ID: <20050930160952.GB13616@linux-mips.org>
References: <cda58cb8050926000665f843dc@mail.gmail.com> <20050926115539.GB3175@linux-mips.org> <cda58cb805092605057f7cad7d@mail.gmail.com> <20050929234542.GB3983@linux-mips.org> <cda58cb80509300536q42e9ddd4q@mail.gmail.com> <20050930130928.GA3083@linux-mips.org> <cda58cb80509300844v5181d6fey@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda58cb80509300844v5181d6fey@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9102
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1003
Lines: 25

On Fri, Sep 30, 2005 at 05:44:01PM +0200, Franck wrote:

> > > 2005/9/30, Ralf Baechle <ralf@linux-mips.org>:
> > > > There are no CONFIG_CPU_4KSC and CONFIG_CPU_4KSD configuration options.
> > > > Did you really create this patch against the linux module of the CVS
> > > > repository or was it a different tree?
> > > >
> > >
> > > The patch was created against linux-mips CVS repository. I added 4KSC
> > > and 4KSD support in this tree. I thougth seeing reference of 4KSC
> > > somewhere. Anyway, if you don't want to include them in your tree
> > > that's ok.
> >
> > It's just that references to CONFIG_* symbols that are being defined
> > nowhere don't make sense.  If however you want to contribute improved
> > support for these processors, by all means I'm certainly going to appreciate
> > a patch!
> >
> 
> I'm surprised you're interested in added support for 4KSC and 4KSD
> cpu...Anyway I could send a trivial patch to you if so.

Yes, some people do strange things with Linux :-)

  Ralf

From dom@mips.com Fri Sep 30 20:47:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 20:47:19 +0100 (BST)
Received: from alg145.algor.co.uk ([62.254.210.145]:61199 "EHLO
	dmz.algor.co.uk") by ftp.linux-mips.org with ESMTP id S3465590AbVI3TrB
	(ORCPT <rfc822;linux-mips@linux-mips.org>);
	Fri, 30 Sep 2005 20:47:01 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1ELQoL-0003Jm-00; Fri, 30 Sep 2005 20:44:49 +0100
Received: from olympia.mips.com ([192.168.192.128] helo=boris)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1ELQqC-0002BW-00; Fri, 30 Sep 2005 20:46:44 +0100
From:	Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17213.38447.42728.297338@mips.com>
Date:	Fri, 30 Sep 2005 20:46:55 +0100
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org
Subject: Re: RFC: Revise n32 ptrace interface
In-Reply-To: <20050930000550.GE3983@linux-mips.org>
References: <20050922182601.GA10829@nevyn.them.org>
	<20050930000550.GE3983@linux-mips.org>
X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.846,
	required 4, AWL, BAYES_00)
Return-Path: <dom@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9103
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 699
Lines: 22


Ralf Baechle (ralf@linux-mips.org) writes:

> I quite deliberately did omit DSP support from 64-bit ptrace(2); there
> is currently no MIPS64 processor with DSP support that I know of.

This is true so far. 

But assuming that 64-bit processing becomes increasingly interesting
(which seems certain) and that some kind of DSP support with extra
registers remains attractive (which seems fairly likely)... well, I'd
have said that any 64-bit MIPS CPU configured from now on is quite
likely to have extra DSP registers.

So while "you aren't going to need it" for a while, anyone thinking of
doing a non-compatible change to ptrace might want to reserve some
space for these registers.

--
Dominic



From drow@nevyn.them.org Fri Sep 30 21:34:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 30 Sep 2005 21:35:00 +0100 (BST)
Received: from nevyn.them.org ([66.93.172.17]:51893 "EHLO nevyn.them.org")
	by ftp.linux-mips.org with ESMTP id S3465592AbVI3Uei (ORCPT
	<rfc822;linux-mips@linux-mips.org>); Fri, 30 Sep 2005 21:34:38 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1ELRaU-0004rx-35; Fri, 30 Sep 2005 16:34:34 -0400
Date:	Fri, 30 Sep 2005 16:34:34 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Dominic Sweetman <dom@mips.com>
Cc:	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: RFC: Revise n32 ptrace interface
Message-ID: <20050930203434.GA18321@nevyn.them.org>
References: <20050922182601.GA10829@nevyn.them.org> <20050930000550.GE3983@linux-mips.org> <17213.38447.42728.297338@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17213.38447.42728.297338@mips.com>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 9104
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 990
Lines: 26

On Fri, Sep 30, 2005 at 08:46:55PM +0100, Dominic Sweetman wrote:
> 
> Ralf Baechle (ralf@linux-mips.org) writes:
> 
> > I quite deliberately did omit DSP support from 64-bit ptrace(2); there
> > is currently no MIPS64 processor with DSP support that I know of.
> 
> This is true so far. 
> 
> But assuming that 64-bit processing becomes increasingly interesting
> (which seems certain) and that some kind of DSP support with extra
> registers remains attractive (which seems fairly likely)... well, I'd
> have said that any 64-bit MIPS CPU configured from now on is quite
> likely to have extra DSP registers.
> 
> So while "you aren't going to need it" for a while, anyone thinking of
> doing a non-compatible change to ptrace might want to reserve some
> space for these registers.

In the future they should be added using PTRACE_GETDSPREGS, or
something similar.  No one's designed that yet, so the first person to
need it gets to do it right.

-- 
Daniel Jacobowitz
CodeSourcery, LLC