On Fri, Apr 12, 2002 at 01:49:47PM -0400, Todd Blevins wrote: > > D TX015D0DC.240 > R0015D0D0 6F206B65 726E656C 2E000000 4C696E75 06 *o kernel....Linu* > R0015D0E0 78207665 7273696F 6E20322E 342E392D *x version 2.4.9-* > R0015D0F0 33312E31 424F4F54 20286275 696C6465 *31.1BOOT (builde* > R0015D100 72407333 39302E72 65646861 742E6465 *r@s390.redhat.de* > R0015D110 29202867 63632076 65727369 6F6E2032 *) (gcc version 2* > R0015D120 2E39352E 33203230 30313033 31352028 *.95.3 20010315 (* > R0015D130 72656C65 61736529 29202331 20534D50 *release)) #1 SMP* > R0015D140 20467269 204D6172 20313520 31363A34 * Fri Mar 15 16:4* > R0015D150 333A3434 20434554 20323030 320A0000 *3:44 CET 2002...* [laroche@porky images]$ md5sum *.img 15d844dba9393cd33667e6d894073c1b initrd.img d66eaab336a5bed76f4d66a1eb45817d kernel.img 6a11cec6ef5003c1bd3b3fdc073d80cc tapeinrd.img 228292a024099553913883c53b2028be tapekrnl.img [laroche@porky images]$ # cat /proc/version Linux version 2.4.9-31.1BOOTtape (builder@s390.redhat.de) (gcc version 2.95.3 20010315 (release)) #1 SMP Fri Mar 15 16:30:40 CET 2002 # I have no idea what could be a problem here. Are md5sums ok? Thanks, Florian La Roche > R0015D160 FFFFFFFF FFFFFFFF 00000001 00000001 *................* > R0015D170 00000001 00000001 000000FF 000000FF *................* > R0015D180 000000FF 6B65726E 656C2042 55472061 *....kernel BUG a* > R0015D190 74202573 3A256421 0A002F76 61722F74 *t %s:%d!../var/t* > R0015D1A0 6D702F62 73383530 312F4255 494C442F *mp/bs8501/BUILD/* > R0015D1B0 6B65726E 656C2D32 2E342E39 2F6C696E *kernel-2.4.9/lin* > R0015D1C0 75782F69 6E636C75 64652F6C 696E7578 *ux/include/linux* > R0015D1D0 2F646361 6368652E 68002F76 61722F74 */dcache.h./var/t* > R0015D1E0 6D702F62 73383530 312F4255 494C442F *mp/bs8501/BUILD/* > R0015D1F0 6B65726E 656C2D32 2E342E39 2F6C696E *kernel-2.4.9/lin* > R0015D200 75782F69 6E636C75 64652F6C 696E7578 *ux/include/linux* > R0015D210 2F736368 65642E68 00002F76 61722F74 */sched.h../var/t* > R0015D220 6D702F62 73383530 312F4255 494C442F *mp/bs8501/BUILD/* > R0015D230 6B65726E 656C2D32 2E342E39 2F6C696E *kernel-2.4.9/lin* > R0015D240 75782F69 6E636C75 64652F6C 696E7578 *ux/include/linux* > R0015D250 2F6D6D2E 68002F76 61722F74 6D702F62 */mm.h./var/tmp/b* > R0015D260 73383530 312F4255 494C442F 6B65726E *s8501/BUILD/kern* > R0015D270 656C2D32 2E342E39 2F6C696E 75782F69 *el-2.4.9/linux/i* > R0015D280 6E636C75 64652F6C 696E7578 2F686967 *nclude/linux/hig* > R0015D290 686D656D 2E680000 07000000 4D656D2D *hmem.h......Mem-* > R0015D2A0 696E666F 3A0A0000 46726565 20737761 *info:...Free swa* > R0015D2B0 703A2020 20202020 20253664 6B420A00 *p: %6dkB..* > R0015D2C0 25642070 61676573 206F6620 52414D0A *%d pages of RAM.* > R0015D2D0 00002564 20726573 65727665 64207061 *..%d reserved pa* > R0015D2E0 6765730A 00002564 20706167 65732073 *ges...%d pages s* > R0015D2F0 68617265 640A0000 25642070 61676573 *hared...%d pages* > R0015D300 20737761 70206361 63686564 0A00256C * swap cached..%l* > R0015D310 64207061 67657320 696E2070 61676520 *d pages in page * > > -- > Todd Blevins > > On Fri, 12 Apr 2002, Pete Zaitcev wrote: > > > > From: Todd Blevins <tblevins@cisco.com> > > > Date: Fri, 12 Apr 2002 12:53:02 -0400 (EDT) > > > > > Well, here's a trace if it means anything to you...doing a load psw...if i > > > understand the opcode, we load the doubleword from the address of the 2nd > > > operand in the operation...it contains all 0s: > > > > > > I 00C > > > Tracing active at IPL > > > > OK, this is what I would do. First get that kernel.img into > > a working Linux, then do this: > > > > $ strings kernel.img | grep 'Linux version' > > Linux version 2.4.9-27-t1 (zaitcev@test1.stuttgart.redhat.com) (gcc version 2.95.3 20010315 (release)) #1 SMP Mon Feb 11 22:09:45 CET 2002 > > > > Send the version string to Florian and ask him to find you > > the corresponding System.map. I hope it lingers somewhere > > in the build area... > > > > In System.map find the log_buf value, say 2b1cc0. > > IPL from the reader and when the thing crashes, say > > > > d rux2b1cc0.200 > > > > 512 bytes if often not enough, add more until you reach the > > end of the trace. This assumes that your VM is fresh enough > > to support EBCDIC to ASCII translation in the display. > > > > By the way, since the trace always starts with "Linux", you > > may try to skip getting System.map by asking the trace facility > > to search core for the pattern "Linux" in ASCII. Here's the > > hex values: > > > > [zaitcev@s390 zaitcev]$ echo 'Linux version'| od -x > > 0000000 4c69 6e75 7820 7665 7273 696f 6e0a > > 0000016 > > [zaitcev@s390 zaitcev]$ > > > > -- Pete > > > > > _______________________________________________ > Redhat-s390-list mailing list > Redhat-s390-list@redhat.com > https://listman.redhat.com/mailman/listinfo/redhat-s390-list
