Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux>
  3. Kernel
2.2.0-pre9 ugliness on udb/alpha
asun at saul1
Jan 22, 1999, 12:30 PM
Post #1 of 6 (284 views)
Permalink
how's this for lossage?
i ran ex1.c from the examples threads directory for glibc and got my
udb to break.
-a
the program:
/* Creates two threads, one printing 10000 "a"s, the other printing
10000 "b"s.
Illustrates: thread creation, thread joining. */
#include <stddef.h>
#include <stdio.h>
#include <unistd.h>
#include "pthread.h"
void * process(void * arg)
{
int i;
fprintf(stderr, "Starting process %s\n", (char *) arg);
for (i = 0; i < 10000; i++) {
write(1, (char *) arg, 1);
}
return NULL;
}
int main(void)
{
int retcode;
pthread_t th_a, th_b;
void * retval;
retcode = pthread_create(&th_a, NULL, process, (void *) "a");
if (retcode != 0) fprintf(stderr, "create a failed %d\n", retcode);
retcode = pthread_create(&th_b, NULL, process, (void *) "b");
if (retcode != 0) fprintf(stderr, "create b failed %d\n", retcode);
retcode = pthread_join(th_a, &retval);
if (retcode != 0) fprintf(stderr, "join a failed %d\n", retcode);
retcode = pthread_join(th_b, &retval);
if (retcode != 0) fprintf(stderr, "join b failed %d\n", retcode);
return 0;
}
here's the ksymoops:
ex1(564): Instruction fault 4
pc = [<fffffc0000462bb4>] ra = [<fffffc000041dd64>] ps = 0000
r0 = 0000000000000000 r1 = fffffc0002cc9b60 r2 = 0000000000000000
r3 = 0000000000000000 r4 = fffffc0002cc9b60 r5 = 0000000000000501
r6 = fffffc00026fa0a0 r7 = 0000000800000000 r8 = fffffc0001998000
r16= fffffc0002cc6fa0 r17= 0000000120000aa9 r18= 0000000000000001
r19= 0000000000000001 r20= 0000000000000001 r21= 000003fffffff4c0
r22= 0000000000000008 r23= 00000200002b44c0 r24= fffffc0002cc6fa0
r25= 0000000000000001 r27= fffffc0000462bb0 r28= fffffc0000420f78
gp = fffffc000047fd28 sp = fffffc000199bde8
Code: 00000000 00000000 00462b38 <fffffc00> 00000000 00000000
00000000 0000
>>EIP: fffffc0000462bb4 <fifo_inode_operations+4/a0>
Code: fffffc0000462ba8 <def_fifo_fops+70/78>
0000000000000000 <_EIP>:
Code: fffffc0000462bb0 <fifo_inode_operations+0/a0> 8: 00 46
2b 38 s
tb t0,17920(s2)
Code: fffffc0000462bb4 <fifo_inode_operations+4/a0> c: ff ff
fc 00 c
all_pal 0xfcffff
0000 00000000
Trace: [<fffffc0000420f78>] [<fffffc000033cd0c>] [<fffffc000033cd0c>]
[<fffffc00
003eb340>] [<fffffc0000310ba0>] [<fffffc0000310af8>]
Warning, Code line not seen, dumping what data is available
Trace: fffffc0000420f78 <sprintf+1f78/25a4>
Trace: fffffc000033cd0c <sys_write+14c/1c0>
Trace: fffffc000033cd0c <sys_write+14c/1c0>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.0-pre9 ugliness on udb/alpha [ In reply to ]
kpreslan at zarniwoop
Jan 22, 1999, 9:04 PM
Post #2 of 6 (279 views)
Permalink
I get a similar error installing the Qlogic FC SCSI module on the Alpha.
I first saw this in pre8. It looks like Alpha threads are broken somehow.
Ken
My ksymoops:
scsi_eh_1(387): Instruction fault 4
pc = [<fffffc00004573dc>] ra = [<fffffc000040c704>] ps = 0000
r0 = 0000000000000009 r1 = 0000000000000001 r2 = fffffc0007897df8
r3 = fffffc00060cbd88 r4 = ffffffffffffffff r5 = 000000000000000a
r6 = fffffc0000444009 r7 = fffffc00060c8342 r8 = fffffc00060c8000
r16= fffffc00060cbd88 r17= 0000000000000001 r18= 0000000000000000
r19= 000000000000000a r20= fffffffffffffffb r21= 0000000000000000
r22= fffffc000044adc8 r23= fffffc000040d0c4 r24= fffffc00060cbd88
r25= 000000000000000a r27= fffffc00004573d8 r28= fffffc000040f7d4
gp = fffffc0000476d40 sp = fffffc00060cbcc8
Code: 00000000 00000000 00457360 <fffffc00> 00000000 00000000 00000000 00000000 00000000
>>EIP: fffffc00004573dc <fifo_inode_operations+4/a0>
Code: fffffc00004573d0 <max_files+770/778> 0000000000000000 <_EIP>:
Code: fffffc00004573d8 <fifo_inode_operations+0/a0> 8: 00 45 73 60 .long 0x60734500
Code: fffffc00004573dc <fifo_inode_operations+4/a0> c: ff ff fc 00 call_pal 0xfcffff
Trace: [<fffffc000040f7d4>] [<fffffc000040d0c4>] [<fffffc00003f0050>] [<fffffc00003106e8>] [<fffffc00003effd8>]
Warning, Code line not seen, dumping what data is available
Trace: fffffc000040f7d4 <sprintf+1edc/327a8>
Trace: fffffc000040d0c4 <simple_strtoul+384/548>
Trace: fffffc00003f0050 <scsi_sleep+1640/2560>
Trace: fffffc00003106e8 <__kernel_thread+50/68>
Trace: fffffc00003effd8 <scsi_sleep+15c8/2560>
1 warning issued. Results may not be reliable.
>
>
> how's this for lossage?
>
> i ran ex1.c from the examples threads directory for glibc and got my
> udb to break.
>
> -a
>
> the program:
>
> /* Creates two threads, one printing 10000 "a"s, the other printing
> 10000 "b"s.
> Illustrates: thread creation, thread joining. */
>
> #include <stddef.h>
> #include <stdio.h>
> #include <unistd.h>
> #include "pthread.h"
>
> void * process(void * arg)
> {
> int i;
> fprintf(stderr, "Starting process %s\n", (char *) arg);
> for (i = 0; i < 10000; i++) {
> write(1, (char *) arg, 1);
> }
> return NULL;
> }
>
> int main(void)
> {
> int retcode;
> pthread_t th_a, th_b;
> void * retval;
>
> retcode = pthread_create(&th_a, NULL, process, (void *) "a");
> if (retcode != 0) fprintf(stderr, "create a failed %d\n", retcode);
> retcode = pthread_create(&th_b, NULL, process, (void *) "b");
> if (retcode != 0) fprintf(stderr, "create b failed %d\n", retcode);
> retcode = pthread_join(th_a, &retval);
> if (retcode != 0) fprintf(stderr, "join a failed %d\n", retcode);
> retcode = pthread_join(th_b, &retval);
> if (retcode != 0) fprintf(stderr, "join b failed %d\n", retcode);
> return 0;
> }
>
>
> here's the ksymoops:
>
> ex1(564): Instruction fault 4
> pc = [<fffffc0000462bb4>] ra = [<fffffc000041dd64>] ps = 0000
> r0 = 0000000000000000 r1 = fffffc0002cc9b60 r2 = 0000000000000000
> r3 = 0000000000000000 r4 = fffffc0002cc9b60 r5 = 0000000000000501
> r6 = fffffc00026fa0a0 r7 = 0000000800000000 r8 = fffffc0001998000
> r16= fffffc0002cc6fa0 r17= 0000000120000aa9 r18= 0000000000000001
> r19= 0000000000000001 r20= 0000000000000001 r21= 000003fffffff4c0
> r22= 0000000000000008 r23= 00000200002b44c0 r24= fffffc0002cc6fa0
> r25= 0000000000000001 r27= fffffc0000462bb0 r28= fffffc0000420f78
> gp = fffffc000047fd28 sp = fffffc000199bde8
> Code: 00000000 00000000 00462b38 <fffffc00> 00000000 00000000
> 00000000 0000
>
> >>EIP: fffffc0000462bb4 <fifo_inode_operations+4/a0>
> Code: fffffc0000462ba8 <def_fifo_fops+70/78>
> 0000000000000000 <_EIP>:
> Code: fffffc0000462bb0 <fifo_inode_operations+0/a0> 8: 00 46
> 2b 38 s
> tb t0,17920(s2)
> Code: fffffc0000462bb4 <fifo_inode_operations+4/a0> c: ff ff
> fc 00 c
> all_pal 0xfcffff
>
> 0000 00000000
> Trace: [<fffffc0000420f78>] [<fffffc000033cd0c>] [<fffffc000033cd0c>]
> [<fffffc00
> 003eb340>] [<fffffc0000310ba0>] [<fffffc0000310af8>]
> Warning, Code line not seen, dumping what data is available
>
> Trace: fffffc0000420f78 <sprintf+1f78/25a4>
> Trace: fffffc000033cd0c <sys_write+14c/1c0>
> Trace: fffffc000033cd0c <sys_write+14c/1c0>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.0-pre9 ugliness on udb/alpha [ In reply to ]
rth at twiddle
Jan 23, 1999, 1:55 PM
Post #3 of 6 (278 views)
Permalink
On Fri, Jan 22, 1999 at 10:04:30PM -0600, Kenneth Preslan wrote:
> I get a similar error installing the Qlogic FC SCSI module on the Alpha.
> I first saw this in pre8. It looks like Alpha threads are broken somehow.
>
> Ken
>
> My ksymoops:
>
> scsi_eh_1(387): Instruction fault 4
> pc = [<fffffc00004573dc>] ra = [<fffffc000040c704>] ps = 0000
> r0 = 0000000000000009 r1 = 0000000000000001 r2 = fffffc0007897df8
> r3 = fffffc00060cbd88 r4 = ffffffffffffffff r5 = 000000000000000a
> r6 = fffffc0000444009 r7 = fffffc00060c8342 r8 = fffffc00060c8000
> r16= fffffc00060cbd88 r17= 0000000000000001 r18= 0000000000000000
> r19= 000000000000000a r20= fffffffffffffffb r21= 0000000000000000
> r22= fffffc000044adc8 r23= fffffc000040d0c4 r24= fffffc00060cbd88
> r25= 000000000000000a r27= fffffc00004573d8 r28= fffffc000040f7d4
> gp = fffffc0000476d40 sp = fffffc00060cbcc8
> Code: 00000000 00000000 00457360 <fffffc00> 00000000 00000000 00000000 00000000 00000000
>
> >>EIP: fffffc00004573dc <fifo_inode_operations+4/a0>
Ok, this is clearly the end problem -- this isn't a function, it's data.
As to how we got there... Presuming we got there via a bsr or jsr, the
address is in ra = [<fffffc000040c704>].
> Trace: fffffc000040f7d4 <sprintf+1edc/327a8>
> Trace: fffffc000040d0c4 <simple_strtoul+384/548>
> Trace: fffffc00003f0050 <scsi_sleep+1640/2560>
> Trace: fffffc00003106e8 <__kernel_thread+50/68>
> Trace: fffffc00003effd8 <scsi_sleep+15c8/2560>
The tracelog is suspect -- simple_strtoul doesn't call anything,
though scsi_sleep does call sprintf indirectly. Further, sprintf
isn't 0x1edc bytes long, only 0x68.
I suppose it is possible that something is wrong with kernel_thread
wrt modules. An invalid gp would explain much of this wierdness.
But I remember fixing that up way earlier in the 2.1 series, and I
just went back over that call chain and didn't see anything amiss.
Can you point to any particular change from pre7 that causes the problem?
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.0-pre9 ugliness on udb/alpha [ In reply to ]
rth at twiddle
Jan 23, 1999, 1:59 PM
Post #4 of 6 (277 views)
Permalink
On Fri, Jan 22, 1999 at 11:30:46AM -0800, a sun wrote:
> i ran ex1.c from the examples threads directory for glibc and got my
> udb to break.
Hmm. Given that the test case works on my machine, and that absolutely
nothing in the code path should be system specific, I'm forced to
consider a miscompiled kernel.
What tools did you use?
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.0-pre9 ugliness on udb/alpha [ In reply to ]
kpreslan at zarniwoop
Jan 24, 1999, 12:18 AM
Post #5 of 6 (278 views)
Permalink
> The tracelog is suspect -- simple_strtoul doesn't call anything,
> though scsi_sleep does call sprintf indirectly. Further, sprintf
> isn't 0x1edc bytes long, only 0x68.
>
> I suppose it is possible that something is wrong with kernel_thread
> wrt modules. An invalid gp would explain much of this wierdness.
> But I remember fixing that up way earlier in the 2.1 series, and I
> just went back over that call chain and didn't see anything amiss.
>
> Can you point to any particular change from pre7 that causes the problem?
Well, I tracked down the problem to the call to down_interruptible() around
line 1974 in scsi_error_handler() in scsi_error.c.
Part of the patch from pre7 to pre8 were all those Alpha semaphore
fixes. I wasn't able to boot until you posted your semaphore patch. Since
then I've always gotten this oops. Apparently something in the semaphore
code still isn't right.
Let me know if you want me to instrument the code more to help you isolate the
bug.
Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.0-pre9 ugliness on udb/alpha [ In reply to ]
rth at twiddle
Jan 25, 1999, 11:56 AM
Post #6 of 6 (278 views)
Permalink
On Sun, Jan 24, 1999 at 01:18:18AM -0600, Kenneth Preslan wrote:
> Well, I tracked down the problem to the call to down_interruptible() around
> line 1974 in scsi_error_handler() in scsi_error.c.
Sigh.
r~
--- arch/alpha/lib/semaphore.S.x Mon Jan 25 10:52:50 1999
+++ arch/alpha/lib/semaphore.S Mon Jan 25 10:53:09 1999
@@ -77,7 +77,6 @@
.ent __down_failed_interruptible
__down_failed_interruptible:
ldgp $29,0($27)
- ldgp $29,0($27)
lda $30, -20*8($30)
stq $28, 0*8($30)
stq $0, 1*8($30)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal