>
> On Thu, Dec 01, 2005 at 02:49:03AM +0100, Ivan Warren wrote:
>
> > The build went ok.. however, here is what I get :
> >
> > deb390-1:/tmp# /home/ivan/local/sbin/yaird -v -o junk.img
> > yaird: goal: template, prologue
> (/home/ivan/local/etc/yaird/Default.cfg:52)
> > yaird: action: prologue, {}
> > yaird: goal: module, fbcon
> (/home/ivan/local/etc/yaird/Default.cfg:56)
> > yaird: goal: mountdir, /
> (/home/ivan/local/etc/yaird/Default.cfg:143)
> > yaird error: unsupported device required: dasda (fatal)
>
> Could you test a corrected version?
>
> - cd yaird.bzr
> - bzr pull # get update
> - grep dasd perl/Plan.pm # oops, that was missing
> - make install # rest as before
>
> Thanks,
> Erik
>
Morning Erik !
Apparently we're getting somewhere !
This is how things are going now :
1) Hardware.pm was missing "load CcwDev" and "load CcwMap" (easy fix)
<PATCH>
--- /home/ivan/yaird.bzr/perl/Hardware.pm 2005-12-01
02:24:02.000000000 +0100
+++ /home/ivan/local/lib/yaird/perl/Hardware.pm 2005-12-01
10:34:36.000000000 +0100
@@ -32,6 +32,8 @@
use PciTab;
use UsbDev;
use UsbTab;
+use CcwDev;
+use CcwTab;
package Hardware;
</PATCH>
2) The initramfs gets built :
<LOG>
deb390-1:/boot# /home/ivan/local/sbin/yaird -v -o initrd.img-2.6.14-2-s390x
2.6.14-2-s390x
yaird: goal: template, prologue (/home/ivan/local/etc/yaird/Default.cfg:52)
yaird: action: prologue, {}
yaird: goal: module, fbcon (/home/ivan/local/etc/yaird/Default.cfg:56)
yaird: goal: mountdir, / (/home/ivan/local/etc/yaird/Default.cfg:143)
yaird: action: insmod,
/lib/modules/2.6.14-2-s390x/kernel/drivers/s390/block/dasd_mod.ko
{optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-2-s390x/kernel/drivers/s390/block/dasd_eckd_mod.ko
{optionList=-- }
yaird: hardware: completed css0/0.0.0004/0.0.0108
yaird: action: mkbdev, /dev/dasda {sysname=dasda }
yaird: action: mkbdev, /dev/dasda1 {sysname=dasda/dasda1 }
yaird: action: mount, /mnt {device=/dev/dasda1 fsType=ext3 isRoot=1
options=-o 'errors=remount-ro' }
yaird: goal: template, postlude (/home/ivan/local/etc/yaird/Default.cfg:156)
yaird: action: postlude, {}
deb390-1:/boot#
</LOG>
3) Boot fails :
<LOG>
/bin/cat: /sys/block/dasda/dev: No such file or directory
Waiting 1 seconds for /sys/block/dasda/dev to show up
/bin/cat: /sys/block/dasda/dev: No such file or directory
Waiting 2 seconds for /sys/block/dasda/dev to show up
/bin/cat: /sys/block/dasda/dev: No such file or directory
Waiting 4 seconds for /sys/block/dasda/dev to show up
/bin/cat: /sys/block/dasda/dev: No such file or directory
Waiting 8 seconds for /sys/block/dasda/dev to show up
/bin/cat: /sys/block/dasda/dev: No such file or directory
Waiting 16 seconds for /sys/block/dasda/dev to show up
/bin/cat: /sys/block/dasda/dev: No such file or directory
Device /sys/block/dasda/dev seems to be down.
Debugging opportunity, type ^D to continue.
/bin/dash: can't access tty; job control turned off
# echo /sys/block/*
/sys/block/ram0 /sys/block/ram1 /sys/block/ram10 /sys/block/ram11
/sys/block/ram
12 /sys/block/ram13 /sys/block/ram14 /sys/block/ram15 /sys/block/ram2
/sys/block
/ram3 /sys/block/ram4 /sys/block/ram5 /sys/block/ram6 /sys/block/ram7
/sys/block
/ram8 /sys/block/ram9
# insmod dasd_eckd.ko
insmod: can't read 'dasd_eckd.ko': No such file or directory
# insmod dasd_eckd_mod.ko
insmod: error inserting 'dasd_eckd_mod.ko': -1 File exists
#
</LOG>
Possible explanation :
dasd_mod won't autodetect dasds unless specifically requested to do so !
Apparently, the appropriate parameter would be :
dasd=autodetect
(based on drivers/s390/block/dasd_devmap.c)
However, this would mean guaranteed failure on some dasd configuration
changes (this requires a small explanation of the S/390 and z/Arch I/O
architecture : Each device is known by 2 ids : A subchannel number and a
device number. The "device number" represents the 'physical' connection (ex
: 010A means device 0A on channel 01).. The subchannel number is a sequence
number in the configuration, and *THAT* is what is used to perform I/O
operations (a device cannot be addressed directly by its device number -
ONLY by its subchannel number).. Furthermore, any autodetection scheme would
most probably use that subchannel numbering to name devices (or more exactly
to assign minor numbers). If 0108 is your 1st dasd device it will most
probably be named 'dasda'.. If a new dasd is inserted at 0100, chances are
0108 will now be called 'dasdb' - *however* if dasd_mod is passed a specific
list of dasd devices, the naming will probably remain unchanged - regardless
of any configuration change - the 1st device listed will be named 'dasda').
The sequence numbering is also model dependent. on IBM real iron, they are
usually related to the order in which they appear in the IOCDS (a microcode
configuration file that describes the system's I/O configuration). On z/VM
(IBM's virtualization solution) the numbering is related to the order in
which the devices are declared in the CP directory (The virtual machines
definition file). On hercules (an open source S/370, S/390 and z/Arch
emulator, which I am using for these tests) the subchannels are numbered
based on the order in which they appear in the hercules configuration
file... However, the architecture makes *NO* guarantee whatsoever as to the
actual order and even whether that number remains identical between each POR
(Power On Reset) - The only architectural guarantee is that the numbering is
contiguous (no holes).
I am sorry this is so complicated (maybe *I* am making it more complicated
than it really is !)..
Thanks,
--Ivan
