Which sources are you using? Up until pretty recently, there was a bug in unaligned.c which could cause this. I don't know when it was fixed at SGI, but the fix is in the 2.4.19-pre2 sources at kernel.org. The problem was that the epc value in the exception context was being advanced to the next instruction prior to the invocation of search_exception_table(regs->cp0_epc). The 2.4.19-pre2 code solves the problem by re-ordering the operations and delaying the advancement of epc. My own quick-and-dirty hack was simply to use the unmutilated value which is also available to emulate_load_store_insn(), changing that one line to be "fixup = search_exception_table(pc)". That seems to work. Kevin K. Sanjay Jain wrote: > > hi all, > > I am running a kernel test program which makes following call. > > getpeername(s, tdat[testno].sockaddr,tdat[testno].salen)); > > In one particular case tdat[testno].salen is set to 1 which is a unaligned > and invalid addr. It results in following oops. > > Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, > line > 373: > $0 : 00000000 10000024 00000000 00000005 > $4 : 10000d20 00000000 10000d20 00000001 > $8 : ffffffff 8b179e98 801c6da0 00000003 > $12: 00000000 00000002 8b179ecc 8f9875bc > $16: 8b1954c0 00000001 10000d20 00000001 > $20: 004014e0 10002e08 00000000 0000000d > $24: 00000001 2ac2db50 > $28: 8b178000 8b179e70 7fff7c70 801c6e2c > epc : 00000000801c58d4 > Status : 10009f03 > Cause : 00800010 > > BadAddr: 0000000000000001Process getpeername01 (pid: 9673, > stackpage=8b178000) > Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c > 8020c788 > 8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048 > 8023a65c > 000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731 > 5d00d538 > 8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003 > 00000003 > 7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24 > 00406950 > 8b1954c0 ... > Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>] > [< > 8023a65c>] > [<801c69b8>] [<8010dce8>] > > Code: 04600003 00402821 8ce20000 <00002821> 00403021 10a00004 00a01021 > 8fb > f0010 03e00008 > > Is this the expected behavior if an unaligned address is passed in a system > call?
