OOps - very obscure

OOps - very obscure

[Florian Lohoff]

Hi,
here a short oops while trying to run "find" in a glibc 2.2 root
on a Indigo2 with a current cvs 2.4.0 kernel.

Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 1004fc00 fffffff2 00000001
$4 : fffffff2 00000000 00000001 00000000
$8 : 00000000 2abf3a94 8800f4a0 00000004
$12: 8ec57f10 7ffffaf8 8ec57f18 8ec57f18
$16: 8801acf8 00000000 10011510 00000002
$20: 10011510 7ffffdd4 7ffffdcc 00000001
$24: 00000000 2abf3a80
$28: 8ec56000 8ec57ef8 7ffffd10 00000000
epc   : 00000000
Status: 1004fc03
Cause : 30000008
Process find (pid: 227, stackpage=8ec56000)
Stack: 10011510 7ffffd10 88028344 00000000 7ffffc80 00402440 2aca4e00 2ac95d10
       00000000 2ac95d10 10011510 00000002 00000001 8800fa88 000007d1 100234f0
       10011510 00000000 00000003 00012000 00000000 1004fc01 00001035 00000000
       000007d1 10011510 00000001 00000000 0000fc00 00000010 00000000 8ec57f0c
       8ec57f10 8ec57f14 8ec57ef8 8ec57efc 2aca4e00 2ac95d10 10011510 00000002
       00000001 ...
Call Trace: [<88028344>] [<8800fa88>]
Code: (Bad address in epc)

I cant identify which system.map ist the correct one - -ETOMANYKERNEL
i extracted this from /proc/ksyms

8800ecb8 __rwsem_wake
8801122c do_gettimeofday

88027394 del_timer
8802869c flush_signals

This oops is reproduceable but not really nice as the fsck takes
~30 minutes :)

I'll build a fresh kernel and retry ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: OOps - very obscure

[Florian Lohoff]

On Wed, Jan 24, 2001 at 04:30:48PM +0100, Florian Lohoff wrote:
> Hi,
> here a short oops while trying to run "find" in a glibc 2.2 root
> on a Indigo2 with a current cvs 2.4.0 kernel.
> 
> Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000

Decoded this is:

Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000
$0 : 00000000 1004fc00 fffffff2 00000001
$4 : fffffff2 00000000 00000001 00000000
$8 : 00000000 2abf3a94 8800f4a0 00000004
$12: 8ec09f10 7ffffaf8 8ec09f18 8ec09f18
$16: 8801acf8 00000000 10011510 00000002
$20: 10011510 7ffffdd8 7ffffdcc 00000002
$24: 00000000 2abf3a80
$28: 8ec08000 8ec09ef8 7ffffd10 00000000
epc   : 00000000
Using defaults from ksymoops -t elf32-bigmips -a mips:3000
Status: 1004fc03
Cause : 30000008
Process find (pid: 242, stackpage=8ec08000)
Stack: 10011510 7ffffd10 88028344 00000000 7ffffc80 00402440 2aca4e00 2ac95d10
       00000000 2ac95d10 10011510 00000002 00000001 8800fa88 000007d1 100235b0
       10011510 00000000 00000003 00012000 00000000 1004fc01 00001035 00000000
       000007d1 10011510 00000001 00000000 0000fc00 00000010 00000000 8ec09f0c
       8ec09f10 8ec09f14 8ec09ef8 8ec09efc 2aca4e00 2ac95d10 10011510 00000002
       00000001 ...
Call Trace: [<88028344>] [<8800fa88>]
Code: (Bad address in epc)
Warning (Oops_code): trailing garbage ignored on Code: line
  Text: 'Code: (Bad address in epc)'
  Garbage: 'ress in epc)'
Warning (Oops_code_values): Code looks like message, not hex digits.  No disassembly attempted.

>>RA;  00000000 Before first symbol
>>PC;  00000000 Before first symbol
Trace; 88028344 <sys_nanosleep+190/24c>
Trace; 8800fa88 <stack_done+1c/38>

I guess the "Garbage" stuff has to be fixed in ksymoops

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: OOps - very obscure

[Florian Lohoff]

On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
> On Wed, Jan 24, 2001 at 04:30:48PM +0100, Florian Lohoff wrote:

> Process find (pid: 242, stackpage=8ec08000)
> Stack: 10011510 7ffffd10 88028344 00000000 7ffffc80 00402440 2aca4e00 2ac95d10
>        00000000 2ac95d10 10011510 00000002 00000001 8800fa88 000007d1 100235b0
>        10011510 00000000 00000003 00012000 00000000 1004fc01 00001035 00000000
>        000007d1 10011510 00000001 00000000 0000fc00 00000010 00000000 8ec09f0c
>        8ec09f10 8ec09f14 8ec09ef8 8ec09efc 2aca4e00 2ac95d10 10011510 00000002
>        00000001 ...
[...]
> >>RA;  00000000 Before first symbol
> >>PC;  00000000 Before first symbol
> Trace; 88028344 <sys_nanosleep+190/24c>
> Trace; 8800fa88 <stack_done+1c/38>

This is the relevant code piece in sys_nanosleep:

    88028338:   af820000        sw      $v0,0($gp)
    8802833c:   0e006b70        jal     8801adc0 <schedule_timeout>
    88028340:   00642021        addu    $a0,$v1,$a0
    88028344:   50400028        beqzl   $v0,880283e8 <sys_nanosleep+0x234>
    88028348:   00001021        move    $v0,$zero
    8802834c:   12000025        beqz    $s0,880283e4 <sys_nanosleep+0x230>

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: OOps - very obscure

[Keith Owens]

On Wed, 24 Jan 2001 16:59:19 +0100, 
Florian Lohoff <flo@rfc822.org> wrote:
>Code: (Bad address in epc)
>Warning (Oops_code): trailing garbage ignored on Code: line
>  Text: 'Code: (Bad address in epc)'
>  Garbage: 'ress in epc)'
>Warning (Oops_code_values): Code looks like message, not hex digits.  No disassembly attempted.
>I guess the "Garbage" stuff has to be fixed in ksymoops

ksymoops understands "(Bad EIP value.*)", it does not know about "(Bad
address in epc)".  I will add it to ksymoops 2.4.1.

Re: OOps - very obscure

[Florian Lohoff]

On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:

> Decoded this is:

> >>RA;  00000000 Before first symbol
> >>PC;  00000000 Before first symbol
> Trace; 88028344 <sys_nanosleep+190/24c>
> Trace; 8800fa88 <stack_done+1c/38>

I am trying to track this down a bit more:

with strace (very old version) 

rt_sigaction(34, {SIG_DFL}, NULL, 16)   = 0
rt_sigprocmask(SIG_BLOCK, [], NULL, 16) = 0
sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
[... repeated this 2 lines ...]

Every 1000 lines or something:

nanosleep({0, 2000001}, NULL)           = 0

But with strace it doesnt crash it seems at least not within 10 Minutes
i let it run ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: OOps - very obscure

[Jun Sun]

Florian,

What is the kernel version?  Your symptom seems to remind me the corrupted s0
bug in several syscalls. The bug is fixed around test9 I believe.  Check for
"save_static_function(sys_sigsuspend);" statement in arch/mips/kernel/signal.c
file.  If you have it, then you don't have the bug.


Jun

Florian Lohoff wrote:
> 
> On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
> 
> > Decoded this is:
> 
> > >>RA;  00000000 Before first symbol
> > >>PC;  00000000 Before first symbol
> > Trace; 88028344 <sys_nanosleep+190/24c>
> > Trace; 8800fa88 <stack_done+1c/38>
> 
> I am trying to track this down a bit more:
> 
> with strace (very old version)
> 
> rt_sigaction(34, {SIG_DFL}, NULL, 16)   = 0
> rt_sigprocmask(SIG_BLOCK, [], NULL, 16) = 0
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> sched_yield(0x7d1, 0x2ac95d24, 0x1, 0, 0x2acfad50) = 0
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> [... repeated this 2 lines ...]
> 
> Every 1000 lines or something:
> 
> nanosleep({0, 2000001}, NULL)           = 0
> 
> But with strace it doesnt crash it seems at least not within 10 Minutes
> i let it run ...
> 
> Flo
> --
> Florian Lohoff                  flo@rfc822.org             +49-5201-669912
>      Why is it called "common sense" when nobody seems to have any?

Re: OOps - very obscure

[Florian Lohoff]

On Thu, Jan 25, 2001 at 10:59:07AM -0800, Jun Sun wrote:
> Florian,
> 
> What is the kernel version?  Your symptom seems to remind me the corrupted s0
> bug in several syscalls. The bug is fixed around test9 I believe.  Check for
> "save_static_function(sys_sigsuspend);" statement in arch/mips/kernel/signal.c
> file.  If you have it, then you don't have the bug.

2.4.0 final - checkout on 20010111

And i have it ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

[FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Florian Lohoff]

On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
> Decoded this is:
> 
> Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000
> $0 : 00000000 1004fc00 fffffff2 00000001
> $4 : fffffff2 00000000 00000001 00000000
> $8 : 00000000 2abf3a94 8800f4a0 00000004
> $12: 8ec09f10 7ffffaf8 8ec09f18 8ec09f18
> $16: 8801acf8 00000000 10011510 00000002
> $20: 10011510 7ffffdd8 7ffffdcc 00000002
> $24: 00000000 2abf3a80
> $28: 8ec08000 8ec09ef8 7ffffd10 00000000
> epc   : 00000000
> Using defaults from ksymoops -t elf32-bigmips -a mips:3000
> Status: 1004fc03
> Cause : 30000008

Ok - another one (sorry to spam you) 

>From "handle_sys" i see that system call address and no of
args are in t2 and t3 which are 0x8800f4a0 and 4 with the register
dump above.

8800f4a0 is sys_sysmips which i also saw in the find strace.

>From the strace i find

sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149

all the time - 0x7d1 is "MIPS_ATOMIC_SET" - Ok from the trace
i see the call comes from handle_sys which itself would end with
o32_ret_from_sys_call.

sysmips(MIPS_ATOMIC_SET, ...) 

would itself return with "ret_from_sys_call".

If i now apply

Index: arch/mips/kernel/sysmips.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
retrieving revision 1.15
diff -u -r1.15 sysmips.c
--- arch/mips/kernel/sysmips.c	2000/11/18 01:19:35	1.15
+++ arch/mips/kernel/sysmips.c	2001/01/25 15:48:44
@@ -111,7 +111,7 @@
 
 		__asm__ __volatile__(
 			"move\t$29, %0\n\t"
-			"j\tret_from_sys_call"
+			"j\to32_ret_from_sys_call"
 			: /* No outputs */
 			: "r" (&cmd));
 		/* Unreached */

The machine now at least doesnt crash anymore - Others have to decide
if this is correct. (Nevertheless find doesnt return but this might
be a different problem)

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

[FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Florian Lohoff]

On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
> Decoded this is:
> 
> Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000
> $0 : 00000000 1004fc00 fffffff2 00000001
> $4 : fffffff2 00000000 00000001 00000000
> $8 : 00000000 2abf3a94 8800f4a0 00000004
> $12: 8ec09f10 7ffffaf8 8ec09f18 8ec09f18
> $16: 8801acf8 00000000 10011510 00000002
> $20: 10011510 7ffffdd8 7ffffdcc 00000002
> $24: 00000000 2abf3a80
> $28: 8ec08000 8ec09ef8 7ffffd10 00000000
> epc   : 00000000
> Using defaults from ksymoops -t elf32-bigmips -a mips:3000
> Status: 1004fc03
> Cause : 30000008

Ok - another one (sorry to spam you) 

From "handle_sys" i see that system call address and no of
args are in t2 and t3 which are 0x8800f4a0 and 4 with the register
dump above.

8800f4a0 is sys_sysmips which i also saw in the find strace.

From the strace i find

sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149

all the time - 0x7d1 is "MIPS_ATOMIC_SET" - Ok from the trace
i see the call comes from handle_sys which itself would end with
o32_ret_from_sys_call.

sysmips(MIPS_ATOMIC_SET, ...) 

would itself return with "ret_from_sys_call".

If i now apply

Index: arch/mips/kernel/sysmips.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
retrieving revision 1.15
diff -u -r1.15 sysmips.c
--- arch/mips/kernel/sysmips.c	2000/11/18 01:19:35	1.15
+++ arch/mips/kernel/sysmips.c	2001/01/25 15:48:44
@@ -111,7 +111,7 @@
 
 		__asm__ __volatile__(
 			"move\t$29, %0\n\t"
-			"j\tret_from_sys_call"
+			"j\to32_ret_from_sys_call"
 			: /* No outputs */
 			: "r" (&cmd));
 		/* Unreached */

The machine now at least doesnt crash anymore - Others have to decide
if this is correct. (Nevertheless find doesnt return but this might
be a different problem)

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Origin 200 crash

[nick]

When booting any of three different kernels I have found, including a
working one from Bacchus I get this:
>> bootp():
Setting $netaddr to 10.1.1.2 (from server 10.1.1.1)
Obtaining  from server 10.1.1.1
1464880+388016+339100 entry: 0xa800000000188000
ARCH: SGI-IP27
PROMLIB: ARC firmware Version 64 Revision 0
Discovered 1 cpus on 1 nodes
Total memory probed : 0x14000 pages
Linux version 2.4.0-test11 (ralf@dbear.engr.sgi.com) (gcc version
egcs-2.91.66 19990314 (egcs-1.1.2 release)) #3 SMP Tue Dec 26 11:0
Loading R10000 MMU routines.
CPU revision is: 00000926
Primary instruction cache 32kb, linesize 64 bytes
Primary data cache 32kb, linesize 32 bytes
Secondary cache sized at 1024K, linesize 128
IP27: Running on node 0.
Node 0 has a primary CPU, CPU is running.
Node 0 has no secondary CPU.
Machine is in M mode.
Cpu 0, Nasid 0x0, pcibr_setup(): found partnum= 0xc002...is bridge
CPU 0 clock is 65535MHz.
On node 0 totalpages: 294912
zone(0): 294912 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: OSLoadOptions=INST
Entering 64-bit mode.
Calibrating delay loop... 179.81 BogoMIPS
Memory: 286120k/327680k available (1430k kernel code, 41560k reserved,
150k data, 208k init)
Dentry-cache hash table entries: 65536 (order: 8, 1048576 bytes)
Buffer-cache hash table entries: 32768 (order: 6, 262144 bytes)
Page-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 32768 (order: 7, 524288 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
REPLICATION: ON nasid 0, ktext from nasid 0, kdata from nasid 0
PCI: Probing PCI hardware on host bus  0.
PCI: Fixing isp1020 in [bus:slot.fn] 00:00.0
PCI: Fixing isp1020 in [bus:slot.fn] 00:01.0
PCI: Fixing base addresses for IOC3 device 00:02.0
PCI: Fixing base addresses for IOC3 device 00:05.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
ttyS00 at iomem 0x9200000008620178 (irq = 0) is a 16550ASHARE_IRQ
SERIAL_PCI enabled
ttyS01 at iomem 0x9200000008920178 (irq = 0) is a 16550A
Using PHY 31, vendor 0x20005c0, model 0, rev 1.
eth0:  MII transceiver found at MDIO address 31, config 3100 status 786f.
IOC3 SSRAM has 128 kbyte.
Found DS1981U NIC registration number 2a:e8:02:00:70:5e, CRC b9.
Ethernet address is 08:00:69:05:77:36.
Using PHY 31, vendor 0x20005c0, model 0, rev 1.
eth1:  MII transceiver found at MDIO address 31, config 3100 status 7849.
IOC3 SSRAM has 128 kbyte.
Found DS1981U NIC registration number 49:d1:01:00:70:5e, CRC dc.
Ethernet address is 08:00:69:05:45:f1.
SCSI subsystem driver Revision: 1.00
qlogicisp : new isp1020 revision ID (5)
qlogicisp : new isp1020 revision ID (5)
scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 00 irq 4 I/O base
0x8200000
scsi1 : QLogic ISP1020 SCSI on PCI bus 00 device 08 irq 5 I/O base
0x8400000
Got dbe at 0xffffffff8013f43c
Cpu 0
$0      : 0000000000000000 0000000014201ce0 a80000000028d040
a80000000028d000
$4      : a80000000028d080 0000000000000000 0000000000000040
ffffffff801ccc80
$8      : 0000000014201ce1 0000000000000000 0000000000000004
0000000000000000
$12     : 0000000000000000 a80000000028d080 ffffffffffffffff
a80000000028d014
$16     : 0000000000000040 0000000014201ce1 a80000000028d040
0000000000000002
$20     : a800000047ffcc00 a8000000002e8800 0000000000000000
a8000000002e88b8
$24     : 0000000000000040 a8000000002e8800
$28     : a800000003678000 a80000000367bb20 a800000003667c30
ffffffff800ddacc
Hi      : 0000000000000000
Lo      : 0000000000000040
epc     : ffffffff8013f43c
badvaddr: a800000047ffde60
badvaddr: a800000047ffde60
Status  : 14201ce2
Cause   : 0000901c
Cause   : 0000901c
Index:  0 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  1 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  2 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  3 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  4 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  5 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  6 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  7 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  8 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index:  9 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 10 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 11 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 12 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 13 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 14 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 15 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 16 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 17 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 18 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 19 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 20 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 21 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 22 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 23 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 24 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 25 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 26 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 27 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 28 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 29 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 30 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 31 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 32 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 33 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 34 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 35 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 36 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 37 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 38 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 39 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 40 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 41 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 42 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 43 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 44 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 45 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 46 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 47 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 48 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 49 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 50 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 51 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 52 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 53 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 54 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 55 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 56 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 57 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 58 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 59 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 60 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 61 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 62 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 63 pgmask=00000000 va=c0000fff80000000 asid=00  [pa=000000 c=0 d=0
v=0 g=0]  [pa=000000 c=0 d=0 v=0 g=0]

Any suggestions/ideas?
	Thanks
		Nick

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Joe deBlaquiere]

I'm trying to implement MIPS_ATOMIC_SET for the Vr4181, which has no ll, 
sc operations. It looks to me like the function does something like

sysmips(MIPS_ATOMIC_SET,ptr,val)
{

}

Florian Lohoff wrote:

> On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
> 
>> Decoded this is:
>> 
>> Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 00000000
>> $0 : 00000000 1004fc00 fffffff2 00000001
>> $4 : fffffff2 00000000 00000001 00000000
>> $8 : 00000000 2abf3a94 8800f4a0 00000004
>> $12: 8ec09f10 7ffffaf8 8ec09f18 8ec09f18
>> $16: 8801acf8 00000000 10011510 00000002
>> $20: 10011510 7ffffdd8 7ffffdcc 00000002
>> $24: 00000000 2abf3a80
>> $28: 8ec08000 8ec09ef8 7ffffd10 00000000
>> epc   : 00000000
>> Using defaults from ksymoops -t elf32-bigmips -a mips:3000
>> Status: 1004fc03
>> Cause : 30000008
> 
> 
> Ok - another one (sorry to spam you) 
> 
>>From "handle_sys" i see that system call address and no of
> args are in t2 and t3 which are 0x8800f4a0 and 4 with the register
> dump above.
> 
> 8800f4a0 is sys_sysmips which i also saw in the find strace.
> 
>>From the strace i find
> 
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> 
> all the time - 0x7d1 is "MIPS_ATOMIC_SET" - Ok from the trace
> i see the call comes from handle_sys which itself would end with
> o32_ret_from_sys_call.
> 
> sysmips(MIPS_ATOMIC_SET, ...) 
> 
> would itself return with "ret_from_sys_call".
> 
> If i now apply
> 
> Index: arch/mips/kernel/sysmips.c
> ===================================================================
> RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
> retrieving revision 1.15
> diff -u -r1.15 sysmips.c
> --- arch/mips/kernel/sysmips.c	2000/11/18 01:19:35	1.15
> +++ arch/mips/kernel/sysmips.c	2001/01/25 15:48:44
> @@ -111,7 +111,7 @@
>  
>  		__asm__ __volatile__(
>  			"move\t$29, %0\n\t"
> -			"j\tret_from_sys_call"
> +			"j\to32_ret_from_sys_call"
>  			: /* No outputs */
>  			: "r" (&cmd));
>  		/* Unreached */
> 
> The machine now at least doesnt crash anymore - Others have to decide
> if this is correct. (Nevertheless find doesnt return but this might
> be a different problem)
> 
> Flo


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Joe deBlaquiere]

that didn't make sense, did it... ;o)

what I meant to say is that it works like

sysmips(MIPS_ATOMIC_SET,ptr,val)
{
	 *ptr = val ;
	val 0 ;
}

but it is an atomic operation

if this correct in a pseudo-code sense?

Joe deBlaquiere wrote:

> I'm trying to implement MIPS_ATOMIC_SET for the Vr4181, which has no ll, 
> sc operations. It looks to me like the function does something like
> 
> sysmips(MIPS_ATOMIC_SET,ptr,val)
> {
> 
> }
> 
> Florian Lohoff wrote:
> 
>> On Wed, Jan 24, 2001 at 04:59:19PM +0100, Florian Lohoff wrote:
>> 
>>> Decoded this is:
>>> 
>>> Unable to handle kernel paging request at virtual address 00000000, 
>>> epc == 00000000, ra == 00000000
>>> $0 : 00000000 1004fc00 fffffff2 00000001
>>> $4 : fffffff2 00000000 00000001 00000000
>>> $8 : 00000000 2abf3a94 8800f4a0 00000004
>>> $12: 8ec09f10 7ffffaf8 8ec09f18 8ec09f18
>>> $16: 8801acf8 00000000 10011510 00000002
>>> $20: 10011510 7ffffdd8 7ffffdcc 00000002
>>> $24: 00000000 2abf3a80
>>> $28: 8ec08000 8ec09ef8 7ffffd10 00000000
>>> epc   : 00000000
>>> Using defaults from ksymoops -t elf32-bigmips -a mips:3000
>>> Status: 1004fc03
>>> Cause : 30000008
>> 
>> 
>> 
>> Ok - another one (sorry to spam you)
>> 
>>>  From "handle_sys" i see that system call address and no of
>> 
>> args are in t2 and t3 which are 0x8800f4a0 and 4 with the register
>> dump above.
>> 
>> 8800f4a0 is sys_sysmips which i also saw in the find strace.
>> 
>>>  From the strace i find
>> 
>> 
>> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
>> 
>> all the time - 0x7d1 is "MIPS_ATOMIC_SET" - Ok from the trace
>> i see the call comes from handle_sys which itself would end with
>> o32_ret_from_sys_call.
>> 
>> sysmips(MIPS_ATOMIC_SET, ...)
>> would itself return with "ret_from_sys_call".
>> 
>> If i now apply
>> 
>> Index: arch/mips/kernel/sysmips.c
>> ===================================================================
>> RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
>> retrieving revision 1.15
>> diff -u -r1.15 sysmips.c
>> --- arch/mips/kernel/sysmips.c    2000/11/18 01:19:35    1.15
>> +++ arch/mips/kernel/sysmips.c    2001/01/25 15:48:44
>> @@ -111,7 +111,7 @@
>>  
>>          __asm__ __volatile__(
>>              "move\t$29, %0\n\t"
>> -            "j\tret_from_sys_call"
>> +            "j\to32_ret_from_sys_call"
>>              : /* No outputs */
>>              : "r" (&cmd));
>>          /* Unreached */
>> 
>> The machine now at least doesnt crash anymore - Others have to decide
>> if this is correct. (Nevertheless find doesnt return but this might
>> be a different problem)
>> 
>> Flo


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Ralf Baechle]

On Thu, Jan 25, 2001 at 01:35:23PM -0600, Joe deBlaquiere wrote:

> sysmips(MIPS_ATOMIC_SET,ptr,val)
> {
> 	 *ptr = val ;
> 	val 0 ;
> }
> 
> but it is an atomic operation
> 
> if this correct in a pseudo-code sense?

It's more:

sysmips(MIPS_ATOMIC_SET, ptr, val)
{
	result = *ptr;
	*ptr = val;

	return result;
}

   Ralf

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Joe deBlaquiere]

Ralf,
	Thanks for the help. I generally consider myself a pseudo-expert on 
Linux, but at the same time I'm amazed by how much I learn on a daily basis.

So I've got the following code which seems to work... (I can't use the 
ll/sc ops on the Vr41xx since they are not implemeted!)

#ifdef CONFIG_CPU_VR41XX
	/* this version is inherently single processor! */
	
	case MIPS_ATOMIC_SET: {
		unsigned int tmp;
		unsigned long flags;

		p = (int *) arg1;
		errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
		if (errno)
			return errno;
		errno = 0;

		/* the Vr processors can't be SMP, so just lock ints */
		save_and_cli(flags);
		tmp = *p ;
		*p = arg2 ;
		restore_flags(flags);
		return tmp;

	}
#endif

The trailer in the normal call is like :

		/* We're skipping error handling etc.  */
		if (current->ptrace & PT_TRACESYS)
			syscall_trace();

		__asm__ __volatile__(
			"move\t$29, %0\n\t"
			"j\tret_from_sys_call"
			: /* No outputs */
			: "r" (&cmd));
		/* Unreached */

Which says "no outputs" although sysmips is specified as

extern int sysmips __P ((__const cmd, __const int arg1,
			 __const int arg2, __const int arg3));

and the usage of this call in glibc pthreads implies that there should 
be a return value. Should I be bypassing the scheduler to return also?

The end goal of this is to make pthreads work on the Vr4181...it's 
certainly an interesting task so far...

Ralf Baechle wrote:

> On Thu, Jan 25, 2001 at 01:35:23PM -0600, Joe deBlaquiere wrote:
> 
> 
>> sysmips(MIPS_ATOMIC_SET,ptr,val)
>> {
>> 	 *ptr = val ;
>> 	val 0 ;
>> }
>> 
>> but it is an atomic operation
>> 
>> if this correct in a pseudo-code sense?
> 
> 
> It's more:
> 
> sysmips(MIPS_ATOMIC_SET, ptr, val)
> {
> 	result = *ptr;
> 	*ptr = val;
> 
> 	return result;
> }
> 
>    Ralf


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Maciej W. Rozycki]

On Thu, 25 Jan 2001, Joe deBlaquiere wrote:

> So I've got the following code which seems to work... (I can't use the 
> ll/sc ops on the Vr41xx since they are not implemeted!)
> 
> #ifdef CONFIG_CPU_VR41XX

 You are perfectly correct, with the exception you really want to make it: 

#ifndef CONFIG_CPU_HAS_LLSC

as that's the correct option -- just undef it in arch/mips/config.in for
your CPU like it's done for others already.

 Shame on me I haven't sent the patch for MIPS_ATMIC_SET for non-ll/sc
processors yet.  I have it but it needs a few minor cleanups.

 Ralf, BTW, what do you think if we send a segfault on a memory access
violation instead of returning an error?  That would make the behaviour of
MIPS_ATMIC_SET consistent for any memory contents.  Does anything actually
rely on the function to return an error in such a situation? 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Joe deBlaquiere]

Ralf gently pointed out that there was the possibility of needing to 
fault the page for *p, which couldn't occur with ints off. So here's an 
updated version...

#ifndef CONFIG_CPU_HAS_LLSC
	/* this version is inherently single processor! */
	/* borrowed from Linux-2.4.0-test12 */
	/* mlock/munlock added - jadb@redhat.com */
	
	case MIPS_ATOMIC_SET: {
		unsigned int tmp;
		unsigned int flags;

		p = (int *) arg1;
		errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
		if (errno)
			return errno;
		errno = 0;
		
		/* need to prevent page faults with ints off */
		if (sys_mlock(p,sizeof(*p)) != 0)
		{
			return -EAGAIN;
		}
		
		/* actually _do_ the exchange */
		save_and_cli(flags);
		errno |= __get_user(tmp, p);
		errno |= __put_user(arg2, p);
		restore_flags(flags);
		
		/* i don't think sys_munlock can fail here, and */
		/* I wouldn't know what to do if it did, so no  */
		/* reason to pay attention to the return value  */
		sys_munlock(p,sizeof(*p));

		return tmp;
	}
#endif

comments anyone?

Joe

Maciej W. Rozycki wrote:

> On Thu, 25 Jan 2001, Joe deBlaquiere wrote:
> 
> 
>> So I've got the following code which seems to work... (I can't use the 
>> ll/sc ops on the Vr41xx since they are not implemeted!)
>> 
>> #ifdef CONFIG_CPU_VR41XX
> 
> 
>  You are perfectly correct, with the exception you really want to make it: 
> 
> #ifndef CONFIG_CPU_HAS_LLSC
> 
> as that's the correct option -- just undef it in arch/mips/config.in for
> your CPU like it's done for others already.
> 
>  Shame on me I haven't sent the patch for MIPS_ATMIC_SET for non-ll/sc
> processors yet.  I have it but it needs a few minor cleanups.
> 
>  Ralf, BTW, what do you think if we send a segfault on a memory access
> violation instead of returning an error?  That would make the behaviour of
> MIPS_ATMIC_SET consistent for any memory contents.  Does anything actually
> rely on the function to return an error in such a situation? 
> 
>   Maciej


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Ralf Baechle]

On Fri, Jan 26, 2001 at 09:41:49AM -0600, Joe deBlaquiere wrote:

> 		sys_munlock(p,sizeof(*p));

> 
> comments anyone?

Mlock(2) doesn't nest.  So if the page was mlocked before, you just unlocked
it.

  Ralf

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Maciej W. Rozycki]

On Fri, 26 Jan 2001, Joe deBlaquiere wrote:

> Ralf gently pointed out that there was the possibility of needing to 
> fault the page for *p, which couldn't occur with ints off. So here's an 
> updated version...

 I don't think you get a page fault that would lead to an inconsistent
state.  See below:

> 		/* actually _do_ the exchange */
> 		save_and_cli(flags);
> 		errno |= __get_user(tmp, p);

 You may get a page fault on accessing *p here.  Not a problem.  When we
return to the faulting "lw" instruction, it will fetch the current value
of *p whether it changed before or not.  Also the TLB will get filled here
if needed. 

> 		errno |= __put_user(arg2, p);

 You may get a page fault on accessing *p here.  But since interrupts are
disabled since getting back from the page fault at the above "lw"
instruction, no context switch could have happened, so the page *p lies on
is already swapped in.  So the only reason of the fault might be write
protection (read protection was already checked by the fault above).  In
this case we don't care if *p changed meanwhile as we won't write it
anyway.  TLB got already filled above so no TLB fault will happen. 

> 		restore_flags(flags);

 Remember we are running UP.

 If anyone sees any other page fault scenario I would be pleased to read
it. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Ralf Baechle]

On Fri, Jan 26, 2001 at 11:21:43AM +0100, Maciej W. Rozycki wrote:

>  Ralf, BTW, what do you think if we send a segfault on a memory access
> violation instead of returning an error?  That would make the behaviour of
> MIPS_ATMIC_SET consistent for any memory contents.  Does anything actually
> rely on the function to return an error in such a situation? 

Afaik the only user of MIPS_ATOMIC_SET ever running on Linux/MIPS is the
Linuxthreads code you wrote, so no.  Aside of that the semantics of this
syscall were defined by older MIPS operating systems such as Risc/OS and
I think we should follow their example.

  Ralf

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Maciej W. Rozycki]

On Fri, 26 Jan 2001, Ralf Baechle wrote:

> Afaik the only user of MIPS_ATOMIC_SET ever running on Linux/MIPS is the
> Linuxthreads code you wrote, so no.  Aside of that the semantics of this
> syscall were defined by older MIPS operating systems such as Risc/OS and
> I think we should follow their example.

 I still haven't seen a definite spec for the call.  Since you suggest the
Linuxthreads code is the only user of the code (also remember the
_test_and_set library function as specified by the ABI), we might abandon
MIPS_ATOMIC_SET and write a _test_and_set syscall instead.  No
compatibility issues would be involved and the definition is clear in the
ABI (the library function would become a simple wrapper). 

 I'm still uncertain if wasting a syscall number is that great idea, but
we would be free from any compatibility problems.  And yes, I still think
an ll/sc emulation could be done independently anyway. 

 Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Ralf Baechle]

On Sat, Jan 27, 2001 at 08:28:05AM +0100, Maciej W. Rozycki wrote:

> > Afaik the only user of MIPS_ATOMIC_SET ever running on Linux/MIPS is the
> > Linuxthreads code you wrote, so no.  Aside of that the semantics of this
> > syscall were defined by older MIPS operating systems such as Risc/OS and
> > I think we should follow their example.
> 
>  I still haven't seen a definite spec for the call.

Sorry, the specs is code and docs I have access to here inside SGI and which
I cannot pass on ...

>  Since you suggest the Linuxthreads code is the only user of the code
> (also remember the _test_and_set library function as specified by the ABI),
> we might abandon MIPS_ATOMIC_SET and write a _test_and_set syscall
> instead.  No compatibility issues would be involved and the definition is
> clear in the ABI (the library function would become a simple wrapper). 

We have an IRIX 5 emulation and if I remember right for IRIX 5
MIPS_ATOMIC_SET is still supported, so we need to also.  So I fear we'll
have to keep sysmips.  Which still doesn't mean we should come up with
something better.

>  I'm still uncertain if wasting a syscall number is that great idea, but
> we would be free from any compatibility problems.  And yes, I still think
> an ll/sc emulation could be done independently anyway. 

  Ralf

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Maciej W. Rozycki]

On Sat, 27 Jan 2001, Ralf Baechle wrote:

> Sorry, the specs is code and docs I have access to here inside SGI and which
> I cannot pass on ...

 Hmm, weird -- I thought a manual page would be available somewhere, as
it's practised in Unix.  Error conditions is what would be most
interesting.

> We have an IRIX 5 emulation and if I remember right for IRIX 5
> MIPS_ATOMIC_SET is still supported, so we need to also.  So I fear we'll
> have to keep sysmips.  Which still doesn't mean we should come up with
> something better.

 OK, then, but still we should do it properly, even for MIPS1.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Jun Sun]

On Thu, Jan 25, 2001 at 06:53:44PM -0600, Joe deBlaquiere wrote:
> 
> The end goal of this is to make pthreads work on the Vr4181...it's 
> certainly an interesting task so far...
> 

We have got pthreads working on Vr4181 for a couple of months already.
What version of kernel are you using?  The toughest problem is not
MIPS_AUTOMIC_SET.  It is a kernel s0 register corruption bug, which is
already fixed in the current CVS tree.

Jun

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Joe deBlaquiere]

Jun Sun wrote:

> On Thu, Jan 25, 2001 at 06:53:44PM -0600, Joe deBlaquiere wrote:
> 
>> The end goal of this is to make pthreads work on the Vr4181...it's 
>> certainly an interesting task so far...
>> 
> 
> 
> We have got pthreads working on Vr4181 for a couple of months already.
> What version of kernel are you using?  The toughest problem is not
> MIPS_AUTOMIC_SET.  It is a kernel s0 register corruption bug, which is
> already fixed in the current CVS tree.
> 

which current CVS tree, the linuxvr tree?

what is the s0 register corruption bug?

> Jun


-- 
Joe

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Jun Sun]

On Fri, Jan 26, 2001 at 02:38:15PM -0600, Joe deBlaquiere wrote:
> 
> Jun Sun wrote:
> 
> > On Thu, Jan 25, 2001 at 06:53:44PM -0600, Joe deBlaquiere wrote:
> > 
> >> The end goal of this is to make pthreads work on the Vr4181...it's 
> >> certainly an interesting task so far...
> >> 
> > 
> > 
> > We have got pthreads working on Vr4181 for a couple of months already.
> > What version of kernel are you using?  The toughest problem is not
> > MIPS_AUTOMIC_SET.  It is a kernel s0 register corruption bug, which is
> > already fixed in the current CVS tree.
> > 
> 
> which current CVS tree, the linuxvr tree?
> 

What do you think "CVS tree" is on an oss.sgi.com mailing list? :-0

> what is the s0 register corruption bug?
> 

Check back with the mailing list archive.  There was a thread about this.  
Basically, the s0 register can be corrupted during a few syscalls.  
pthread_create() uses one of the syscalls and thus fails even though the 
new thread is actually created.

Jun

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call

[Florian Lohoff]

On Thu, Jan 25, 2001 at 02:19:52PM -0800, Ralf Baechle wrote:
> It's more:
> 
> sysmips(MIPS_ATOMIC_SET, ptr, val)
> {
> 	result = *ptr;
> 	*ptr = val;
> 
> 	return result;
> }

If thats the case - shouldnt the attached patch fix the sysmips stuff ?
I stumbled once again over sysmips - To get a MIPS ISA I compatible
glibc 2.2.2 you need to compile it with sysmips(MIPS_ATOMIC_SET, ...)
which breaks badly with "Illegal Instruction" on current cvs kernels.


Index: arch/mips/kernel/sysmips.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/sysmips.c,v
retrieving revision 1.17
diff -u -r1.17 sysmips.c
--- arch/mips/kernel/sysmips.c	2001/02/09 21:05:46	1.17
+++ arch/mips/kernel/sysmips.c	2001/04/04 22:09:18
@@ -75,7 +75,6 @@
 	}
 
 	case MIPS_ATOMIC_SET: {
-		unsigned int tmp;
 
 		p = (int *) arg1;
 		errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
@@ -98,7 +97,7 @@
 			".word\t1b, 3b\n\t"
 			".word\t2b, 3b\n\t"
 			".previous\n\t"
-			: "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno)
+			: "=&r" (retval), "=o" (* (u32 *) p), "=r" (errno)
 			: "r" (arg2), "o" (* (u32 *) p), "2" (errno)
 			: "$1");
 
@@ -109,15 +108,7 @@
 		if (current->ptrace & PT_TRACESYS)
 			syscall_trace();
 
-		((struct pt_regs *)&cmd)->regs[2] = tmp;
-		((struct pt_regs *)&cmd)->regs[7] = 0;
-
-		__asm__ __volatile__(
-			"move\t$29, %0\n\t"
-			"j\to32_ret_from_sys_call"
-			: /* No outputs */
-			: "r" (&cmd));
-		/* Unreached */
+		goto out;
 	}
 
 	case MIPS_FIXADE:


What makes me wonder is that we try to return -EFAULT and stuff
which then limits the values for MIPS_ATOMIC_SET to positive ints. 
I dont think this is correct.

Comments ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call)

[Wichert Akkerman]

Previously Florian Lohoff wrote:
> From the strace i find
> 
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149

FWIW, I've just put code in strace CVS to decode this properly. Looking
in my (stock Linus) kerneltree I noticed the sys_sysmips code assumes
it can get away with converting an int to a char*, which seems like a
wrong assumption to me..

I don't have my indy up and running at the moment, so the code is
completely untested. Feedback is welcomed :)

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

newbie question.

[Can Altineller]

	Hello;

	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
running Irix on it. What is the status of the sgi port port of linux. Is
there a distro available? Also, I dont have a floppy in my indy, so can I
net boot? If someone point me out in the correct way, I will be very
happy.

	Thanks.
	-C.A.

Re: newbie question.

[David Jez]

On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
> 
> 	Hello;
> 
> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
> running Irix on it. What is the status of the sgi port port of linux. Is
> there a distro available? Also, I dont have a floppy in my indy, so can I
> net boot? If someone point me out in the correct way, I will be very
> happy.
Hi,

Try download doc & faqs & tutorials & distro from:

ftp://ftp.oss.sgi.com/pub/linux/mips

or RedHat from:

ftp://ftp.oss.sgi.com/pub/linux/mips/redhat

PS: Don't worry about instalation. In directory redhat you can find Getting
started and README. Read it carefully. If you search archive of this conf. you
can find thread about netbooting Indy ( bootp():/vmlinuz ) from PROM monitor
and setting bootpd in linux boot server.
> 
> 	Thanks.
> 	-C.A.
> 
> 
Best Regards,
Dave

-- 
-------------------------------------------------------
  David "Dave" Jez                Brno, CZ, Europe
 E-mail: dave.jez@seznam.cz
PGP key: finger xjezda00@fest.stud.fee.vutbr.cz
---------=[ ~EOF ]=------------------------------------

Re: newbie question.

[Mike McDonald]

>Date:   Tue, 20 Feb 2001 08:06:10 +0100
>From: David Jez <dave.jez@seznam.cz>
>To: Can Altineller <altine@ee.fit.edu>
>Subject: Re: newbie question.
>
>On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
>> 
>> 	Hello;
>> 
>> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
>> running Irix on it. What is the status of the sgi port port of linux. Is
>> there a distro available? Also, I dont have a floppy in my indy, so can I
>> net boot? If someone point me out in the correct way, I will be very
>> happy.
>Hi,
>
>Try download doc & faqs & tutorials & distro from:
>
>ftp://ftp.oss.sgi.com/pub/linux/mips

  Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
(I've heard there's a FAQ someplace but I've never found it.)


  Mike McDonald
  mikemac@mikemac.com

Re: newbie question.

[nick]

www.foobazco.org is the faq I have used.
	Nick

On Tue, 20 Feb 2001, Mike McDonald wrote:

> 
> >Date:   Tue, 20 Feb 2001 08:06:10 +0100
> >From: David Jez <dave.jez@seznam.cz>
> >To: Can Altineller <altine@ee.fit.edu>
> >Subject: Re: newbie question.
> >
> >On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
> >> 
> >> 	Hello;
> >> 
> >> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
> >> running Irix on it. What is the status of the sgi port port of linux. Is
> >> there a distro available? Also, I dont have a floppy in my indy, so can I
> >> net boot? If someone point me out in the correct way, I will be very
> >> happy.
> >Hi,
> >
> >Try download doc & faqs & tutorials & distro from:
> >
> >ftp://ftp.oss.sgi.com/pub/linux/mips
> 
>   Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
> FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
> (I've heard there's a FAQ someplace but I've never found it.)
> 
> 
>   Mike McDonald
>   mikemac@mikemac.com
> 

Re: newbie question.

[Ralf Baechle]

On Tue, Feb 20, 2001 at 12:26:11PM -0800, Mike McDonald wrote:

>   Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
> FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
> (I've heard there's a FAQ someplace but I've never found it.)

Write 100 times: http://oss.sgi.com/mips/mips-howto.html ;-)

  Ralf

Re: strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call)

[Ralf Baechle]

On Mon, Feb 19, 2001 at 02:11:30PM +0100, Wichert Akkerman wrote:

> > sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> 
> FWIW, I've just put code in strace CVS to decode this properly. Looking
> in my (stock Linus) kerneltree I noticed the sys_sysmips code assumes
> it can get away with converting an int to a char*, which seems like a
> wrong assumption to me..
> 
> I don't have my indy up and running at the moment, so the code is
> completely untested. Feedback is welcomed :)

Some versions of the kernel were simply not return anything usefull, so
the the value in $v0 stayed unchanged; 4149 is the syscall number of
sysmips(2).

  Ralf