Re: 2.2.18pre16 on sparc64 (Ultra1): Remaining troubles

2000-10-16 Thread David S. Miller

   Date: Mon, 16 Oct 2000 12:35:36 -0300
   From: Horst von Brand <[EMAIL PROTECTED]>

   depmod -ae gives unresolved symbols pci_dvma_v2p_hash (hadn't the
   PCI stuff been gouged out?) and empty_zero_page in: misc/ffb.o,
   net/skfp.o, scsi/sr_mod.o.

I don't get this with the default "arch/sparc64/defconfig"
configuration, and in fact I have used the FFB drm/dri driver.
Could you try that out?  That is what I test.  If that works for you,
we can then dissect what is different about the config you chose which
makes it fail.

It only builds as a module BTW, the drm.o archive is linked into the
"ffb.o" driver, which is why is appears to be build "non-modular".

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.18pre16 on sparc64 (Ultra1): Remaining troubles

2000-10-16 Thread Horst von Brand

This is an (up to date, mildly hacked) RH 6.2 machine. Problems I still
see:

  floppy.c: In function `result':
  floppy.c:1168: warning: `status' might be used uninitialized in this function

Bogus gcc warning.

  floppy.c: In function `floppy_interrupt':
  floppy.c:1760: warning: unused variable `cpu'

Due to this being an UP machine, I assume (it is used as
"softirq_endlock(cpu)" a few lines down).

BTW, why isn't this module-able on sparcs?

  make[4]: Entering directory `/usr/src/linux-2.2.18pre/drivers/char/drm'
  rm -f drm.o
  ar rcs drm.o

This makes no sense...

In drivers/char/drm/memory.c (as module):

  memory.c:45: warning: `drm_mem_lock' defined but not used

Sure enough, UP vs SMP again. There are several more of these.

In drivers/sbus/bpp.c:

  bpp.c: In function `map_bpp':
  bpp.c:963: warning: format argument is not a pointer (arg 4)

The offending printk() is:

  printk("bpp%d.map_bpp: 0x%x.%p[0x%x] i=%d\n", idx,
 dev->reg_addrs[0].which_io, dev->reg_addrs[0].phys_addr,
 dev->reg_addrs[0].reg_size, dev->irqs[0]);

I assume phys_addr is just a long, so this should be %x instead of %p? Or
%04x/%08x depending on architecture... brrr!

In drivers/sbus/audio/dbri.c:

Lots of places that assume sizeof(int) == sizeof(pointer). Some of them are
just format problems, fixed thus (I think). Others I don't dare touch. Plus
a load of "`loops_per_jiffy' undeclared (first use in this function)".

--- linux-2.2.18pre/drivers/sbus/audio/dbri.c-dist-2.2.18pre16  Wed May  3 20:16:44 
2000
+++ linux-2.2.18pre/drivers/sbus/audio/dbri.c   Mon Oct 16 11:14:50 2000
@@ -358,8 +358,8 @@
 
 if (callback != NULL) {
 spin_unlock(>pipes[pipe].spinlock);
-dprintk(D_USR, ("DBRI: xmit callback %08x(%08x)\n",
-(int)callback, (int)callback_arg));
+dprintk(D_USR, ("DBRI: xmit callback %p(%p)\n",
+callback, callback_arg));
 callback(callback_arg, status & 0xe);
 spin_lock(>pipes[pipe].spinlock);
 }
@@ -421,8 +421,8 @@
 spin_unlock(>pipes[pipe].spinlock);
 
 if (callback != NULL) {
-dprintk(D_USR, ("DBRI: recv callback %08x(%08x)\n",
-(int)callback, (int)callback_arg));
+dprintk(D_USR, ("DBRI: recv callback %p(%p)\n",
+callback, callback_arg));
 
 callback(callback_arg, DBRI_RD_STATUS(status), count);
 }
@@ -1624,8 +1624,8 @@
 {
struct dbri *dbri = (struct dbri *)drv->private;
 
-dprintk(D_USR, ("DBRI: start audio output buf=%x/%ld\n",
-(int) buffer, count));
+dprintk(D_USR, ("DBRI: start audio output buf=%p/%ld\n",
+buffer, count));
 
 mmcodec_setdata(dbri);
 
@@ -1676,8 +1676,8 @@
 /* Pipe 6 is audio receive */
 recv_on_pipe(dbri, 6, buffer, len,
  _audio_input_callback, (void *)drv);
-dprintk(D_USR, ("DBRI: start audio input buf=%x/%ld\n",
-(int)buffer, len));
+dprintk(D_USR, ("DBRI: start audio input buf=%p/%ld\n",
+buffer, len));
 }
 
 static void dbri_stop_input(struct sparcaudio_driver *drv)

fs/coda/upcall.c has its share of mismatches too: lines 388, 534, 560,
2x654.

depmod -ae gives unresolved symbols pci_dvma_v2p_hash (hadn't the PCI stuff
been gouged out?) and empty_zero_page in: misc/ffb.o, net/skfp.o,
scsi/sr_mod.o.

BTW, mounting NFS to Solaris 2.6 doesn't work, mounting from there works.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.2.18pre16 on sparc64 (Ultra1): Remaining troubles

2000-10-16 Thread David S. Miller

   Date: Mon, 16 Oct 2000 12:35:36 -0300
   From: Horst von Brand [EMAIL PROTECTED]

   depmod -ae gives unresolved symbols pci_dvma_v2p_hash (hadn't the
   PCI stuff been gouged out?) and empty_zero_page in: misc/ffb.o,
   net/skfp.o, scsi/sr_mod.o.

I don't get this with the default "arch/sparc64/defconfig"
configuration, and in fact I have used the FFB drm/dri driver.
Could you try that out?  That is what I test.  If that works for you,
we can then dissect what is different about the config you chose which
makes it fail.

It only builds as a module BTW, the drm.o archive is linked into the
"ffb.o" driver, which is why is appears to be build "non-modular".

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/