I have been playing around with linux on an ultra60,
and have had some struggles with the kernel.
The most annoying one is that somewhere in between
kernels 2.4.7 and 2.4.12 someone delete the define
of INIT_MMAP from the processor.h of sparc64, which
doesnt really help when trying to compile a kernel.
Putting in the define of 2.4.7 got me on the way.
So putting it back might be a nice idea ;)
Ow well, still better as solaris, for my purposes
atleast.
--
Sten Spans
Don't use AC kernels, I do not keep track of them and therefore
Sparc64 builds are likely to not work.
Use Linus's kernels, I keep him uptodate with all the latest
changes and I make sure his releases compile on sparc64.
Franks a lot,
David S. Miller
[email protected]
On Sun, 21 Oct 2001, David S. Miller wrote:
>
> Don't use AC kernels, I do not keep track of them and therefore
> Sparc64 builds are likely to not work.
>
> Use Linus's kernels, I keep him uptodate with all the latest
> changes and I make sure his releases compile on sparc64.
ahah, I had quite a few problems getting framebuffer, dri
and all to work on each kernel that I overlooked that.
With the linux 2.4.12 I cant seem to get dri to compile
for instance.
drivers/char/drm/drm.o: In function `ffb_vm_shm_nopage':
drivers/char/drm/drm.o(.text+0x4ba8): undefined reference to
`virt_to_bus_not_defined_use_pci_map'
drivers/char/drm/drm.o: In function `ffb_vm_dma_nopage':
drivers/char/drm/drm.o(.text+0x4e4c): undefined reference to
`virt_to_bus_not_defined_use_pci_map'
make: *** [vmlinux] Error 1
The main annoiance is the 3.5mb size limitation
which one reaches quite quickly.
ow well, I am gonna trow a some time at the 3ware driver
to see how long it'll take before I give up trying to get
it to work on sparc64 ;).
So long and give the penguin some fish.
--
Sten Spans
DRI works perfectly fine in my current sources, patches below.
Wrt the 3.5MB size limitation, use modules man.
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/drm_drv.h linux/drivers/char/drm/drm_drv.h
--- vanilla/linux/drivers/char/drm/drm_drv.h Fri Sep 14 14:04:07 2001
+++ linux/drivers/char/drm/drm_drv.h Thu Oct 18 09:03:58 2001
@@ -1047,6 +1047,25 @@
atomic_inc( &dev->counts[_DRM_STAT_UNLOCKS] );
+#if __HAVE_KERNEL_CTX_SWITCH
+ /* We no longer really hold it, but if we are the next
+ * agent to request it then we should just be able to
+ * take it immediately and not eat the ioctl.
+ */
+ dev->lock.pid = 0;
+ {
+ __volatile__ unsigned int *plock = &dev->lock.hw_lock->lock;
+ unsigned int old, new, prev, ctx;
+
+ ctx = lock.context;
+ do {
+ old = *plock;
+ new = ctx;
+ prev = cmpxchg(plock, old, new);
+ } while (prev != old);
+ }
+ wake_up_interruptible(&dev->lock.lock_queue);
+#else
DRM(lock_transfer)( dev, &dev->lock.hw_lock->lock,
DRM_KERNEL_CONTEXT );
#if __HAVE_DMA_SCHEDULE
@@ -1061,6 +1080,7 @@
DRM_ERROR( "\n" );
}
}
+#endif /* !__HAVE_KERNEL_CTX_SWITCH */
unblock_all_signals();
return 0;
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/drm_vm.h linux/drivers/char/drm/drm_vm.h
--- vanilla/linux/drivers/char/drm/drm_vm.h Thu Oct 18 19:06:21 2001
+++ linux/drivers/char/drm/drm_vm.h Sat Oct 20 04:40:42 2001
@@ -531,10 +531,17 @@
vma->vm_flags |= VM_IO; /* not in core dump */
}
offset = DRIVER_GET_REG_OFS();
+#ifdef __sparc__
+ if (io_remap_page_range(vma->vm_start,
+ VM_OFFSET(vma) + offset,
+ vma->vm_end - vma->vm_start,
+ vma->vm_page_prot, 0))
+#else
if (remap_page_range(vma->vm_start,
VM_OFFSET(vma) + offset,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
+#endif
return -EAGAIN;
DRM_DEBUG(" Type = %d; start = 0x%lx, end = 0x%lx,"
" offset = 0x%lx\n",
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/ffb_drv.c linux/drivers/char/drm/ffb_drv.c
--- vanilla/linux/drivers/char/drm/ffb_drv.c Sun Aug 12 11:23:32 2001
+++ linux/drivers/char/drm/ffb_drv.c Thu Oct 18 09:03:58 2001
@@ -1,4 +1,4 @@
-/* $Id: ffb_drv.c,v 1.15 2001/08/09 17:47:51 davem Exp $
+/* $Id: ffb_drv.c,v 1.16 2001/10/18 16:00:24 davem Exp $
* ffb_drv.c: Creator/Creator3D direct rendering driver.
*
* Copyright (C) 2000 David S. Miller ([email protected])
@@ -45,16 +45,16 @@
#define DRIVER_PRESETUP() do { \
int _ret; \
_ret = ffb_presetup(dev); \
- if(_ret != 0) return _ret; \
+ if (_ret != 0) return _ret; \
} while(0)
/* Free private structure */
#define DRIVER_PRETAKEDOWN() do { \
- if(dev->dev_private) kfree(dev->dev_private); \
+ if (dev->dev_private) kfree(dev->dev_private); \
} while(0)
#define DRIVER_POSTCLEANUP() do { \
- if(ffb_position != NULL) kfree(ffb_position); \
+ if (ffb_position != NULL) kfree(ffb_position); \
} while(0)
/* We have to free up the rogue hw context state holding error or
@@ -66,7 +66,9 @@
int idx; \
\
idx = context - 1; \
- if (fpriv && fpriv->hw_state[idx] != NULL) { \
+ if (fpriv && \
+ context != DRM_KERNEL_CONTEXT && \
+ fpriv->hw_state[idx] != NULL) { \
kfree(fpriv->hw_state[idx]); \
fpriv->hw_state[idx] = NULL; \
} \
On Sun, Oct 21, 2001 at 06:15:23PM -0700, David S. Miller wrote:
>
> DRI works perfectly fine in my current sources, patches below.
On a side note of coding style, the following:
> +#ifdef __sparc__
> + if (io_remap_page_range(vma->vm_start,
> + VM_OFFSET(vma) + offset,
> + vma->vm_end - vma->vm_start,
> + vma->vm_page_prot, 0))
> +#else
> if (remap_page_range(vma->vm_start,
> VM_OFFSET(vma) + offset,
> vma->vm_end - vma->vm_start,
> vma->vm_page_prot))
> +#endif
should really be turned into io_remap_page_range(...) unconditionally
and add a #define for io_remap_page_range in the arch specific code.
Having #ifdef's all over generic code is just ugly.
-ben
On Sun, 21 Oct 2001, David S. Miller wrote:
>
> DRI works perfectly fine in my current sources, patches below.
>
> Wrt the 3.5MB size limitation, use modules man.
mjes, the kernel module loader is nice, it's just
that I know what hardware I have and like to build
a kernel with what I need.
Ow well. I wonder if the dri driver is as funny as the hme one ;)
--
Sten Spans
From: Sten <[email protected]>
Date: Tue, 23 Oct 2001 00:39:35 +0200 (CEST)
mjes, the kernel module loader is nice, it's just
that I know what hardware I have and like to build
a kernel with what I need.
"arch/sparc64/defconfig" handles every onboard necessary device any
machine in my sparc64 collection has, and that kernel is under 3.5MB
It probably encompasses all the hardware you really need too :-)
Franks a lot,
David S. Miller
[email protected]
On Mon, 22 Oct 2001, David S. Miller wrote:
> From: Sten <[email protected]>
> Date: Tue, 23 Oct 2001 00:39:35 +0200 (CEST)
>
> mjes, the kernel module loader is nice, it's just
> that I know what hardware I have and like to build
> a kernel with what I need.
>
> "arch/sparc64/defconfig" handles every onboard necessary device any
> machine in my sparc64 collection has, and that kernel is under 3.5MB
>
> It probably encompasses all the hardware you really need too :-)
Well the thing is that I like todo evil things,
like connecting sgi flatpanels to creator3d's, using
non sun blessed ( aka sub 1000$ ) ethernet cards or
sticking in wierd raid cards.
Which is why I like linux ;)
Having source is great because I can break it,
and maybe learn something in the process.
--
Sten Spans
From: Sten <[email protected]>
Date: Tue, 23 Oct 2001 00:50:42 +0200 (CEST)
Well the thing is that I like todo evil things,
like connecting sgi flatpanels to creator3d's, using
non sun blessed ( aka sub 1000$ ) ethernet cards or
sticking in wierd raid cards.
Which is why I like linux ;)
Having source is great because I can break it,
and maybe learn something in the process.
All of this is irrelevant to going over the 3.5MB mark,
I contend that your machine simply does not need it no matter
what obscure stuff you stick into it :-)
Turn off the PCI device names, that is usually what eats up a
lot of space and lspci provides the same info anyways...
Franks a lot,
David S. Miller
[email protected]
On Mon, 22 Oct 2001, David S. Miller wrote:
> From: Sten <[email protected]>
> Date: Tue, 23 Oct 2001 00:50:42 +0200 (CEST)
>
> Well the thing is that I like todo evil things,
> like connecting sgi flatpanels to creator3d's, using
> non sun blessed ( aka sub 1000$ ) ethernet cards or
> sticking in wierd raid cards.
>
> Which is why I like linux ;)
>
> Having source is great because I can break it,
> and maybe learn something in the process.
>
> All of this is irrelevant to going over the 3.5MB mark,
> I contend that your machine simply does not need it no matter
> what obscure stuff you stick into it :-)
I wonder if pci to isa adaptors exist ;)
> Turn off the PCI device names, that is usually what eats up a
> lot of space and lspci provides the same info anyways...
jup, that's what I came up with as well.
Off to bed now, many more boxen to upgrade tomorrow,
gotta love ptrace. Especially when they annouce the hole
on friday 16:30 just when you prepare for going home.
--
Sten Spans
Hello Dave ,
On Sun, 21 Oct 2001, David S. Miller wrote:
> DRI works perfectly fine in my current sources, patches below.
>
> Wrt the 3.5MB size limitation, use modules man.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why man ! , Alpha does not have this limit ? Why Sparc ?
THese are valid ?'s I beleive . Tia , JimL
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
"David S. Miller" wrote:
> Turn off the PCI device names, that is usually what eats up a
> lot of space and lspci provides the same info anyways...
...after updating lspci's copy of pci.ids, of course :)
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
From: "Mr. James W. Laferriere" <[email protected]>
Date: Mon, 22 Oct 2001 19:18:38 -0400 (EDT)
Why man ! , Alpha does not have this limit ? Why Sparc ?
It has to do with a combination of what OBP guarentees the boot
loader and limitations within the boot signature.
It would require a lot of SILO and kernel work to eliminate.
Franks a lot,
David S. Miller
[email protected]