Re: s390 is totally broken in 2.4.18

Re: s390 is totally broken in 2.4.18

[Martin Schwidefsky]

Hi,

>Apparently, NOBODY bothered to test 2.4.18-pre*, 2.4.18 final,
>or 2.4.19-pre* on s390. The broken patch went into 2.4.18-pre1
>with a curt changelog:
>
>- S390 merge (IBM)
The patch that was merged in 2.4.18-pre* has been created against
2.4.17-pre7 and it did work. The problem is that not all of the
changes I sent Marcelo have been accepted. One of the patches was
the asm-offsets fix that removes all of the hardcoded offsets from
entry.S. Another patch was accepted that changed the thread
structure and this created the inconsistency.

>Patch attached.
Well your patch halfway fixes one of the problems. Halfway because
not the fp_regs structure has changed its size but the pt_regs
pointer has been removed from the thread structure.
Incidentally I sent an s390 update to Marcelo yesterday and the
minimal fixes including an rwsem.h implementation and the partition
detection fixes are about 2000 lines. Want a copy ?

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: s390 is totally broken in 2.4.18

[Pete Zaitcev]

> Subject: Re: s390 is totally broken in 2.4.18
> From: "Martin Schwidefsky" <schwidefsky@de.ibm.com>
> Date: Tue, 5 Mar 2002 11:10:37 +0100
 
> The patch that was merged in 2.4.18-pre* has been created against
> 2.4.17-pre7 and it did work. The problem is that not all of the
> changes I sent Marcelo have been accepted. One of the patches was
> the asm-offsets fix that removes all of the hardcoded offsets from
> entry.S. Another patch was accepted that changed the thread
> structure and this created the inconsistency.

A patch that generated offsets at compilation time would be
a superiour solution. As a matter of fact, I was thinking
about adopting DaveM's script that generates offsets for sparc.
He does it a make dep time in order to prevent mass rebuilds
on every recompile. See arch/sparc64/kernel/check_asm.sh
and the corresponding Makefile. Good thing you mentioned that
and saved me a bunch of work :)

Please keep poking Marcelo with it, and it's a great pity that
you did not before 2.4.18 came out.

> >Patch attached.

> Well your patch halfway fixes one of the problems. Halfway because
> not the fp_regs structure has changed its size but the pt_regs
> pointer has been removed from the thread structure.

Yes, I noticed. However, offsets are all chained together,
so all other offsets become correct. But once again, having
them all generated automatically is preferable.

> Incidentally I sent an s390 update to Marcelo yesterday and the
> minimal fixes including an rwsem.h implementation and the partition
> detection fixes are about 2000 lines. Want a copy ?

Certainly, I do. I worked around the partitions part with "obvious"
fixup:

-       if (ioctl_by_bdev(bdev, HDIO_GETGEO, (unsigned long)geo);
+       if (ioctl_by_bdev(bdev, HDIO_GETGEO, (unsigned long)geo))
-       data = read_dev_sector(bdev, inode->label_block*blocksize, &sect);
+       data = read_dev_sector(bdev, info->label_block*blocksize, &sect);

But that code did not look too good, in particular it was
not checking return codes. So, it was on my TODO list to
clean it up.

-- Pete

Re: s390 is totally broken in 2.4.18

[Martin Schwidefsky]

Hi Pete,

>Certainly, I do. I worked around the partitions part with "obvious"
>fixup:
>
>-       if (ioctl_by_bdev(bdev, HDIO_GETGEO, (unsigned long)geo);
>+       if (ioctl_by_bdev(bdev, HDIO_GETGEO, (unsigned long)geo))
>-       data = read_dev_sector(bdev, inode->label_block*blocksize, &sect);
>+       data = read_dev_sector(bdev, info->label_block*blocksize, &sect);
>
>But that code did not look too good, in particular it was
>not checking return codes. So, it was on my TODO list to
>clean it up.

This won't work. The trouble we have is that a partition detection can be
done in two completely different situations. First the "normal" detection
with a builtin dasd driver. ibm_partition is called with no locks held and
with a non-open block device. Second the detection can be done as part of
a block device open with an automated module load. In this case the
get_blkfops functions requests the module which in turn calls the partition
detection. That is done with the bd_sem semaphore of the block device held.
The call to ioctl_by_bdev with the builtin dasd driver fails because the
block device is not open. So we would need to add an open to the partition
detection but we can't do that because then the automated module load
would dead-lock.
Your hack to get it running only works by chance. The first ioctl_by_bdev
that is supposed to get the block number of the label block will fail as
well. So normally you'll end up loading the wrong block. The hack we are
currently using looks like this:

diff -urN linux-2.4.18/fs/block_dev.c linux-2.4.18-s390/fs/block_dev.c
--- linux-2.4.18/fs/block_dev.c Mon Feb 25 20:38:08 2002
+++ linux-2.4.18-s390/fs/block_dev.c    Fri Mar  1 15:47:25 2002
@@ -530,11 +530,18 @@
 {
        int res;
        mm_segment_t old_fs = get_fs();
+       struct block_device_operations *bd_op;

-       if (!bdev->bd_op->ioctl)
+       bd_op = bdev->bd_op;
+       if (bd_op == NULL) {
+               bd_op = blkdevs[MAJOR(to_kdev_t(bdev->bd_dev))].bdops;
+               if (bd_op == NULL)
+                       return -EINVAL;
+       }
+       if (!bd_op->ioctl)
                return -EINVAL;
        set_fs(KERNEL_DS);
-       res = bdev->bd_op->ioctl(bdev->bd_inode, NULL, cmd, arg);
+       res = bd_op->ioctl(bdev->bd_inode, NULL, cmd, arg);
        set_fs(old_fs);
        return res;
 }

The idea is to get ioctl_by_bdev to work for non-open devices. But it is
a hack because I do not safe-guard against module unloading.

blue skies,
   Martin

P.S. I will sent you the patches I sent Marcelo in a private mail.

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

s390 is totally broken in 2.4.18

[Pete Zaitcev]

Apparently, NOBODY bothered to test 2.4.18-pre*, 2.4.18 final,
or 2.4.19-pre* on s390. The broken patch went into 2.4.18-pre1
with a curt changelog:

- S390 merge                                    (IBM)

Patch attached.

-- Pete

--- linux-2.4.18-0.1.s390/arch/s390/kernel/entry.S	Mon Feb 25 11:37:56 2002
+++ linux-2.4.18-0.1-x.s390/arch/s390/kernel/entry.S	Mon Mar  4 19:53:13 2002
@@ -59,7 +59,7 @@
  */
 _TSS_PTREGS  = 0
 _TSS_FPRS    = (_TSS_PTREGS+8)
-_TSS_AR2     = (_TSS_FPRS+136)
+_TSS_AR2     = (_TSS_FPRS+128)
 _TSS_AR4     = (_TSS_AR2+4)
 _TSS_KSP     = (_TSS_AR4+4)
 _TSS_USERSEG = (_TSS_KSP+4)
--- linux-2.4.18-0.1.s390/arch/s390x/kernel/entry.S	Mon Feb 25 11:37:56 2002
+++ linux-2.4.18-0.1-x.s390/arch/s390x/kernel/entry.S	Mon Mar  4 20:04:24 2002
@@ -60,7 +60,7 @@
  */
 _TSS_PTREGS  = 0
 _TSS_FPRS    = (_TSS_PTREGS+8)
-_TSS_AR2     = (_TSS_FPRS+136)
+_TSS_AR2     = (_TSS_FPRS+128)
 _TSS_AR4     = (_TSS_AR2+4)
 _TSS_KSP     = (_TSS_AR4+4)
 _TSS_USERSEG = (_TSS_KSP+8)