bk 2.4-test7 broken

bk 2.4-test7 broken

[Jack Howarth]

Hello,
    There are several problems with the current bitkeeper unstable
kernel tree. The first two our compilation problems which can be
fixed if someone with write access to bitkeeper will submit these
two patches...

--- linuxppc_2_3/drivers/input/adbhid.c.org	Mon Aug 14 22:59:01 2000
+++ linuxppc_2_3/drivers/input/adbhid.c	Mon Aug 14 22:59:36 2000
@@ -129,9 +129,9 @@
 	if (nb != 3 || (data[0] & 3) != KEYB_KEYREG)
 		return;		/* ignore it */
 	kbd_pt_regs = regs;
-	input_keycode(id, data[1], 0);
+	adbhid_input_keycode(id, data[1], 0);
 	if (!(data[2] == 0xff || (data[2] == 0x7f && data[1] == 0x7f)))
-		input_keycode(id, data[2], 0);
+		adbhid_input_keycode(id, data[2], 0);
 }

 static void



--- linuxppc_2_3/include/asm-ppc/fcntl.h.org	Mon Aug 14 22:54:35 2000
+++ linuxppc_2_3/include/asm-ppc/fcntl.h	Mon Aug 14 22:55:56 2000
@@ -35,6 +35,10 @@
 #define F_SETSIG	10	/*  for sockets. */
 #define F_GETSIG	11	/*  for sockets. */

+#define F_GETLK64	12	/*  using 'struct flock64' */
+#define F_SETLK64	13
+#define F_SETLKW64	14
+
 /* for F_[GET|SET]FL */
 #define FD_CLOEXEC	1	/* actually anything with low bit set goes */

@@ -66,6 +70,14 @@
 	off_t l_start;
 	off_t l_len;
 	pid_t l_pid;
+};
+
+struct flock64 {
+	short  l_type;
+	short  l_whence;
+	loff_t l_start;
+	loff_t l_len;
+	pid_t  l_pid;
 };

 #endif

The third problem is more serious. The resulting kernel gets stuck in
the Freeing unused kernel memory stage. This is similar to the problem
Geert mentioned earlier on the mailing list.

http://lists.linuxppc.org/listarcs/linuxppc-dev/200008/msg00094.html

Unfortunately Geert's purposed patch doesn't solve the problem.
                                 Jack

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Martin Costabel]

Hi,

I too would like to know if somebody has this kernel running.
Jack Howarth wrote:
>
> Hello,
>     There are several problems with the current bitkeeper unstable
> kernel tree. The first two our compilation problems which can be
> fixed if someone with write access to bitkeeper will submit these
> two patches...
>
> --- linuxppc_2_3/drivers/input/adbhid.c.org     Mon Aug 14 22:59:01 2000
> +++ linuxppc_2_3/drivers/input/adbhid.c Mon Aug 14 22:59:36 2000
[]

This one has been mentioned on the list already. I hope someone (Paul?)
will listen this time. The same thing goes for the following patch which
has been published several times but not applied:

--- arch/ppc/kernel/ppc_ksyms.c.ori     Mon Aug 14 09:18:11 2000
+++ arch/ppc/kernel/ppc_ksyms.c         Sun Jul 16 09:06:49 2000
@@ -253,7 +253,7 @@
 EXPORT_SYMBOL(pmac_xpram_read);
 EXPORT_SYMBOL(pmac_xpram_write);
 #endif /* CONFIG_NVRAM */
-#ifdef CONFIG_PPC_RTC
+#ifdef CONFIG_PPC_RTC_MODULE
 EXPORT_SYMBOL(mktime);
 EXPORT_SYMBOL(to_tm);
 #endif


> --- linuxppc_2_3/include/asm-ppc/fcntl.h.org    Mon Aug 14 22:54:35 2000
> +++ linuxppc_2_3/include/asm-ppc/fcntl.h        Mon Aug 14 22:55:56 2000
> @@ -35,6 +35,10 @@
[]

This one has been included in the bitkeeper kernel in the meantime.
On the other hand, the corresponding changeset introduced another bug by
changing the type of the function find_via_cuda() from void to int, but
only its declaration in the header file include/linux/cuda.h and not its
definition in drivers/macintosh/via-cuda.c. Doesn't compile.

> The third problem is more serious. The resulting kernel gets stuck in
> the Freeing unused kernel memory stage. This is similar to the problem
> Geert mentioned earlier on the mailing list.

Mine gets stuck after saying "arch: exit" and before switching from the
prom console to the fb console (no penguin).

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Andreas Tobler]

Martin Costabel wrote:
>
> Hi,
>
> I too would like to know if somebody has this kernel running.

Up to now NO.

>
> This one has been included in the bitkeeper kernel in the meantime.
> On the other hand, the corresponding changeset introduced another bug by
> changing the type of the function find_via_cuda() from void to int, but
> only its declaration in the header file include/linux/cuda.h and not its
> definition in drivers/macintosh/via-cuda.c. Doesn't compile.

Changed the int also in via-cuda.c -> It compiles with warnings.

> > The third problem is more serious. The resulting kernel gets stuck in
> > the Freeing unused kernel memory stage. This is similar to the problem
> > Geert mentioned earlier on the mailing list.
>
> Mine gets stuck after saying "arch: exit" and before switching from the
> prom console to the fb console (no penguin).

On the wallstreet  I get as far as Jack does, but my screen is
unreadable. On the 7200 (601-cpu) I enter the xmon just after arch:exit.
The only thing I see here is this:

vector: 700 at pc = c00061bc, lr = c0004bd4, msr = 81030, sp = c0208f10 [c0208e60]
current = c0207020, pid = 0, comm = swapper.

No key input works..... (also ctrl apple power doesn't maybe due to my
usb & adb combination?)


Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Michel Lanners]

On  15 Aug, this message from Martin Costabel echoed through cyberspace:
> I too would like to know if somebody has this kernel running.

Not me....

> Jack Howarth wrote:
>>     There are several problems with the current bitkeeper unstable
>> kernel tree.
> []
> Mine gets stuck after saying "arch: exit" and before switching from the
> prom console to the fb console (no penguin).

Mine too. I have it stuck at various points, as can be shown by many
ppc_md.progress() calls ;-). Most of the time, it stops somewhere in
init/main.c, in the early stages of start_kernel():

asmlinkage void __init start_kernel(void)
{
[...]
        lock_kernel();
        printk(linux_banner);
        setup_arch(&command_line);
        printk("Kernel command line: %s\n", saved_command_line);
        parse_options(command_line);
[sometimes never comes here.]
        trap_init();
        init_IRQ();
[it can happen in init_IRQ() as well]
        sched_init();
        time_init();
[somewhere in time_init(), I've also seen it crash]
        softirq_init();
[if it got here, it succeeded for me]
[...]

I've tried to trace via ppc_md.progress() calls where it hangs, but
that's quite useles, as it doesn't always hang at the same place.

For the record, I've seen similar hangs with 2.3.99/2.4.0 kernels
before, when I had to reboot a few times before it would succeed. Also,
I'm using quik to boot my 7600/upgraded-G3; I've not had the time to
verify how it's behaving under BootX.

Comments? Solutions?


Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Andreas Tobler]

To answer myself...

Andreas Tobler wrote:

> On the wallstreet  I get as far as Jack does, but my screen is
> unreadable. On the 7200 (601-cpu) I enter the xmon just after arch:exit.
> The only thing I see here is this:
>
> vector: 700 at pc = c00061bc, lr = c0004bd4, msr = 81030, sp = c0208f10 [c0208e60]
> current = c0207020, pid = 0, comm = swapper.

A previous test on linux-pmac-devel(2.4.0-test5) was successful (until
to the adaptec...), so I tought the changes got in in bk too. Nop, a
reminder on a previous mail from Takashi I checked the time.c in
arch/ppc/kernel. The 'mftb' call is still there..... (which the 601
doesn't likes/understands)

So I think a merge between linuxcare-devel and bk isn't done up to now...

Andreas

BTW, on the wallstreet I see the boot log ok when I booted with
BootX.app. So I suppose it's depending on the registers....

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Martin Costabel]

Andreas Tobler wrote:
[]
> A previous test on linux-pmac-devel(2.4.0-test5) was successful (until
> to the adaptec...), so I tought the changes got in in bk too. Nop, a
> reminder on a previous mail from Takashi I checked the time.c in
> arch/ppc/kernel. The 'mftb' call is still there..... (which the 601
> doesn't likes/understands)
>
> So I think a merge between linuxcare-devel and bk isn't done up to now...

Just for the record: I compiled and run OK both
- linux-pmac-devel as rsynced right now (version 2.4.0-test6)
- linux-bk-devel as of 3 days ago (version 2.4.0-test5)

For those of you who get up to "freeing kernel memory": Did you see the
patch on the linux-kernel mailing list for fs/exec.c
http://boudicca.tux.org/hypermail/linux-kernel/latest/0266.html?
A similar patch is contained in the latest (test7-pre4) patch from
Linus.

I am now trying to back out the recent changes to softirq&Cie...

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Ani Joshi]

FWIW, 2.4.0-test7-pre4 (kernel.org)  boots here on a 603e.  Few minor
fixing up needed for the build, perhaps one of you should do a bk vs.
kernel.org diff and find your problem.


ani


On Tue, 15 Aug 2000, Andreas Tobler wrote:

>
> Martin Costabel wrote:
> >
> > Hi,
> >
> > I too would like to know if somebody has this kernel running.
>
> Up to now NO.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bk 2.4-test7 broken

[Martin Costabel]

Ani Joshi wrote:
>
> FWIW, 2.4.0-test7-pre4 (kernel.org)  boots here on a 603e.  Few minor
> fixing up needed for the build, perhaps one of you should do a bk vs.
> kernel.org diff and find your problem.

Seems to have been the right idea. By putting the arch/ppc and
include/asm-ppc directories from linux-pmac-devel into my linux-bk-devel
copy and then applying the kernel.org test7-pre4 patch (plus some minor
fiddling), I have now a kernel that boots, calls itself 2.4.0-test7 and
still has the new input layer from the bk-devel tree.

It also should have the latest patches for RTC, but I cannot test this,
because I get
   hwclock: Open of /dev/rtc failed, errno=2: No such file or directory
just as with Paul's 2.4.0-test6 kernel. I am using devfs, so the
/dev/rtc device should be created automagically, and in 2.4.0-test5 this
worked.

What the problem was is hard to say, because there are now a lot of
diffs to the bk-devel tree.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/