First off, do you have my "multiboot" patch on? :-)
As you can see, the command line area of storage (0x10480) is getting
corrupted. But, what's strange about it is that the bootloader reloads it
from disk even when you do a "shutdown -r" so it's kind of an interesting
problem.
Does it always show the same garbage for the command line when it fails?
The stuff in the log you sent was from the hwinfo package and a hwscan runs
at boot time, but that doesn't mean it's the problem. The information is
stored in /var/lib/hardware or you can see it by using the "hwinfo" command.
If you're willing to play a bit, it might be kind of interesting to see what
the following produces. It isn't gonna fix your problem, but it "might"
help track it down.
Get into CMS and set a breakpoint:
TRACE I R 10000
And just for fun to try and catch the culprit:
TRACE ST INTO 10480.32
Start your IPL: (use correct address)
I 62C
You should break when the bootloader moves the command line to 0x10480:
00: -> 000020E6 MVC D2FF20001000 >> 00010480 00001000 CC 0
Continue with the IPL:
B
When you hit the breakpoint you should receive something like:
00: Tracing active at IPL
00: -> 00010000 LM 980F0180 00000180 CC 0
Now, issue this command to display the contents of your command line:
D TX10480.16
It should produce something like this:
00: R00010480 8481A284 7EF6F2F0 60F6F286 40999696 06 *dasd=620-62f roo*
00: R00010490 A37E6184 85A56184 81A28494 F10A0000 *t=/dev/dasdm1...*
Continue with the IPL:
B
After the IPL is done, display the command line contents again:
D TX10480.16
We should see the same contents:
00: V00010480 8481A284 7EF6F2F0 60F6F286 40999696 06 *dasd=620-62f roo*
00: V00010490 A37E6184 85A56184 81A28494 F10A0000 *t=/dev/dasdm1...*
Now, do the reboot:
shutdown -r now
And try the above steps again until it fails. Then display the storage
again:
D TX10480.16
Like I said, it taint gonna fix your problem, but it "might" be worth the
exercise.
Leland
