All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, zaitcev@redhat.com
Subject: Re: s390 is totally broken in 2.4.18
Date: Tue, 5 Mar 2002 11:43:47 -0500	[thread overview]
Message-ID: <20020305114347.A4062@devserv.devel.redhat.com> (raw)
In-Reply-To: <OF6510BC1D.720C525B-ONC1256B73.003619EE@de.ibm.com>
In-Reply-To: <OF6510BC1D.720C525B-ONC1256B73.003619EE@de.ibm.com>; from schwidefsky@de.ibm.com on Tue, Mar 05, 2002 at 11:10:37AM +0100

> 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

  reply	other threads:[~2002-03-05 16:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-05 10:10 s390 is totally broken in 2.4.18 Martin Schwidefsky
2002-03-05 16:43 ` Pete Zaitcev [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-03-06  9:17 Martin Schwidefsky
2002-03-05  5:23 Pete Zaitcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020305114347.A4062@devserv.devel.redhat.com \
    --to=zaitcev@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.