[ENBD] Re: Problem applying fr1 generic 2.4 patch to Red Hat 9.0 /?2.4.20-8

[Jean-Marc BOUCHER]

Selon "Peter T. Breuer" <ptb at it.uc3m.es>:

> "Also sprach Steve Purkis:"
> > On Sep 7, 2004, at 20:26, Peter T. Breuer wrote:
> > > Steve Purkis <steve.purkis at multimap.com> wrote:
> > >> I'm having troubles applying the fr1 'generic 2.4 kernel patch' on a
> > >> new build of Red Hat Linux 9.0,
> > >
> > > Yo ho ho and a bottle of rum!
> > >
> > >> untouched kernel source 2.4.20 (-8 rpm
> > >
> > > The source is too old for the patch to be applied directly (most
> > > probably).
> > > The patch is made against pure 2.4.25, as I recall, and there look to be
> > > minor differences.
> >
> > Ah, not so generic then -- perhaps update the patch's name?
>
> RH is what is NOT generic :(.
>
> > I'll try out 2.4.25 when I next get a mo, and see how that goes.  Ta
> > for the tip.
>
> I'm not saying you should use 2.4.25 - it should run fine on 2.4.20.
>
> > >>         patching file drivers/md/md.c
> > >>         Hunk #14 FAILED at 3579.
> > >>         1 out of 15 hunks FAILED -- saving rejects to file
> > >> drivers/md/md.c.rej
> > >
> > > I'd check it out and apply by hand.
> >
> > I haven't time, unfortunately, otherwise I would.
>
> It's a question of 30s.  You have to look at the 10 or so lines of the
> md.c.rej reject file (it shows the diff hunk) and apply the appropriate
> change by hand.  RH have probably moved a comma or replaced a space by a
> tab, which will make the automatic patch fail.
>
> Apply the patch to the kernel source (plus the one line fixup by hand).
> That will let you run make more easily.
>
> If the hunk is the one I think it is, it is:
>
> @@ -3540,16 +3741,33 @@
>                  * about not overloading the IO subsystem. (things like an
>                  * e2fsck being done on the RAID array should execute fast)
>                  */
> -               if (md_need_resched(current))
> -                       schedule();
> +               if (md_need_resched(current)) {
> +                        /* PTB this seems not to progress when over loop dev
> */
> +
> +                       current->state = TASK_INTERRUPTIBLE;
> +                       md_schedule_timeout(1);
> +                }
>
>                 currspeed =
> (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
> +#ifdef MD_BITMAP_SUPPORT
> +                /*
> +                 * PTB some of the blocks are skipped, not synced, so
> +                 * should not count when limiting i/o. Let personality say.
> +                 */
> +               realspeed = (j - mddev->resync_mark_cnt -
> atomic_read(&md_throttle[mdidx(mddev)]))/2/((jiffies-mddev->resync_mark)/HZ
> +1) +1;
> +#endif /* MD_BITMAP_SUPPORT */
>
>                 if (currspeed > sysctl_speed_limit_min) {
>                         current->nice = 19;
>
> -                       if ((currspeed > sysctl_speed_limit_max) ||
> -                                       !is_mddev_idle(mddev)) {
> +                       if (
> +#ifdef MD_BITMAP_SUPPORT
> +                        /* PTB use realspeed for upper limit on i/o */
> +                            (realspeed > sysctl_speed_limit_max) ||
> +#else
> +                            (currspeed > sysctl_speed_limit_max) ||
> +#endif /* MD_BITMAP_SUPPORT */
> +                                        !is_mddev_idle(mddev)) {
>                                 current->state = TASK_INTERRUPTIBLE;
>                                 md_schedule_timeout(HZ/4);
>                                 goto repeat;
>
>
> and you can forget the first change (the one that swaps "schedule()"
> for something more elaborate). The middle bit of the hunk adds in a
> calculation of the real speed, to complement the apparent speed
> calculation ("currspeed") just before. The last bit of the hunk changes
> the throttle control to idle when the real speed goes above the set
> limit, not when the apparent speed goes over the limit.
>
> So you could forget all that hunk and it would only affect throttle
> control.
>
> Peter
>
>
> _______________________________________________
> ENBD mailing list
> ENBD at lists.community.tummy.com
> http://lists.community.tummy.com/mailman/listinfo/enbd
>
hi all ;-),

it won't work on 2.4.20 kernel because the sched structure as changed (see
sched.h, no nice member in task_struct structure

regards


-----------------------------------------------------------
Jean-Marc BOUCHER         mailto:jeanmarc.boucher at free.fr
 REDENE - FRANCE          http://jeanmarc.boucher.free.fr