Hi ppl,
just reporting on 2.6.0-test1 on sparcs:
i am trying to compile linux-2.6.0-test1-{mm1,mm2,ac1,ac2)
on 2 differents sparcs, both latest debian sid & gcc-3.2.3:
ultra enterprise 1 (sun4u sparc64)
sparc station 4 (sun4m sparc32)
on both i need to enable PCI support even
when these boxes doesn't have a PCI bus,
i think the main bus is SBUS and i get
errors when compiling the Sun ESP scsi
controller about functions for DMA depending
on PCI. I don't think is convenient for
these old boxes having support for PCI
because enlarge the kernel and it really
doesn't have that type of bus.
And when i enable PCI support the sparc32
compiles fine but hangs inmediately on boot.
The sparc64 doesn't compile with ac2 patch:
arch/sparc64/kernel/built-in.o(.init.text+0x3bcc): In function `pdev_cookie_fillin':
: referencia a `pci_remove_bus_device' sin definir
make: *** [vmlinux] Error 1
The others mentioned kernels hangs when booting.
Yes, i have selected proper configuration for the
CONFIG_INPUT_*=y layer, CONFIG_VT_CONSOLE=y,
CONFIG_HW_CONSOLE=y and CONFIG_PROM_CONSOLE=y.
I even tried both CONFIG_FRAMEBUFFER_CONSOLE set to y/n
Any help will be apreciated as i really want
the 2.6 kernels support both sparc32 and sparc64
boxes, googling i found osinvestor.com/sparc but
is down and in the sparclinux archives there are
patches but they appear to be applied on linus
2.6.0-test1 kernel.
Thanks.
-solca
> Date: Mon, 21 Jul 2003 20:51:42 -0600
> From: Otto Solares <[email protected]>
> ultra enterprise 1 (sun4u sparc64)
> sparc station 4 (sun4m sparc32)
>
> on both i need to enable PCI support even
> when these boxes doesn't have a PCI bus,
I'll look into sparc32 problems when I get from Canada.
-- Pete
On Tue, Jul 22, 2003 at 08:09:05AM -0400, Pete Zaitcev wrote:
> > Date: Mon, 21 Jul 2003 20:51:42 -0600
> > From: Otto Solares <[email protected]>
>
> > ultra enterprise 1 (sun4u sparc64)
> > sparc station 4 (sun4m sparc32)
> >
> > on both i need to enable PCI support even
> > when these boxes doesn't have a PCI bus,
>
> I'll look into sparc32 problems when I get from Canada.
good.
converting the esp scsi driver to sbus without
pci requirement is the right step IMO. Maybe
the scsi people can comment on this.
-solca
On Tue, 22 Jul 2003 12:26:09 -0600
Otto Solares <[email protected]> wrote:
> converting the esp scsi driver to sbus without
> pci requirement is the right step IMO. Maybe
> the scsi people can comment on this.
No, the problem is that SCSI DMA transfer direction
macros are defined in terms of PCI ones. That's all,
it's a minor issue and probably easily solved.
On Tue, Jul 22, 2003 at 05:54:00PM -0700, David S. Miller wrote:
> On Tue, 22 Jul 2003 12:26:09 -0600
> Otto Solares <[email protected]> wrote:
>
> > converting the esp scsi driver to sbus without
> > pci requirement is the right step IMO. Maybe
> > the scsi people can comment on this.
>
> No, the problem is that SCSI DMA transfer direction
> macros are defined in terms of PCI ones. That's all,
> it's a minor issue and probably easily solved.
these are the ofending messages:
In file included from include/asm/dma-mapping.h:1,
from include/linux/dma-mapping.h:13,
from include/scsi/scsi_cmnd.h:4,
from drivers/scsi/scsi.h:20,
from drivers/scsi/scsi.c:57:
include/asm-generic/dma-mapping.h: In function `dma_supported':
include/asm-generic/dma-mapping.h:19: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h:19: (Each undeclared identifier is reported only once
include/asm-generic/dma-mapping.h:19: for each function it appears in.)
include/asm-generic/dma-mapping.h: In function `dma_set_mask':
include/asm-generic/dma-mapping.h:27: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_alloc_coherent':
include/asm-generic/dma-mapping.h:36: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_free_coherent':
include/asm-generic/dma-mapping.h:45: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_map_single':
include/asm-generic/dma-mapping.h:54: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_unmap_single':
include/asm-generic/dma-mapping.h:63: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_map_page':
include/asm-generic/dma-mapping.h:73: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_unmap_page':
include/asm-generic/dma-mapping.h:82: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_map_sg':
include/asm-generic/dma-mapping.h:91: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_unmap_sg':
include/asm-generic/dma-mapping.h:100: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_sync_single':
include/asm-generic/dma-mapping.h:109: `pci_bus_type' undeclared (first use in this function)
include/asm-generic/dma-mapping.h: In function `dma_sync_sg':
include/asm-generic/dma-mapping.h:118: `pci_bus_type' undeclared (first use in this function)
make[2]: *** [drivers/scsi/scsi.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
-solca
On Tue, Jul 22, 2003 at 05:54:00PM -0700, David S. Miller wrote:
> No, the problem is that SCSI DMA transfer direction
> macros are defined in terms of PCI ones. That's all,
> it's a minor issue and probably easily solved.
That's not true, there's not really any SCSI DMA transfer direction
macros anymore, but scsi now uses the generic enum dma_direction directly.
Sparc unfortunately defines the new DMA API in terms of the PCI DMA API
which gets you this mess.
On Wed, 23 Jul 2003 07:07:39 +0100
Christoph Hellwig <[email protected]> wrote:
> Sparc unfortunately defines the new DMA API in terms of the PCI DMA API
> which gets you this mess.
Sparc did not do this, the person coding up the new DMA API
decided it was a good idea to implement the generic version
this way. :-)
I think it's rediculious that I have to implement the whole
new DMA API abstraction thing just to get rid of this PCI
dependency.
Why don't we put the enum dma_direction somewhere else? Some
linux/foo.h header that doesn't require asm/dma*.h
On Tue, Jul 22, 2003 at 11:24:10PM -0700, David S. Miller wrote:
> Sparc did not do this, the person coding up the new DMA API
> decided it was a good idea to implement the generic version
> this way. :-)
>
> I think it's rediculious that I have to implement the whole
> new DMA API abstraction thing just to get rid of this PCI
> dependency.
>
> Why don't we put the enum dma_direction somewhere else? Some
> linux/foo.h header that doesn't require asm/dma*.h
Putting it into linux/dma-mapping.h is fine with me, but I expect to
see more users of the dma-mapping API soon..
On Wed, 23 Jul 2003 07:28:36 +0100
Christoph Hellwig <[email protected]> wrote:
> Putting it into linux/dma-mapping.h is fine with me, but I expect to
> see more users of the dma-mapping API soon..
And unlike this particular scsi layer usage, such drivers will be
dependant upon things like CONFIG_PCI and thus won't get compiled
in unless CONFIG_PCI has been enabled in the kernel configuration.
The enumeration can go into some common area that doesn't care about
the dma-mapping.h actual implementation.
And linux/dma-mapping.h is a bad name to use, call it dma-dir.h or
something, because linux/dma-mapping.h would need to include
asm/dma-mapping.h which is what we're trying to avoid here.
On Tue, Jul 22, 2003 at 11:29:11PM -0700, David S. Miller wrote:
> And unlike this particular scsi layer usage, such drivers will be
> dependant upon things like CONFIG_PCI and thus won't get compiled
> in unless CONFIG_PCI has been enabled in the kernel configuration.
Umm, no. The whole idea of the DMA mapping API is that it's independant
of the underlying bus. Think of usb or ieee1394 drivers doing direct DMA
independant of the bus the underlying host adapter uses.
> And linux/dma-mapping.h is a bad name to use, call it dma-dir.h or
> something, because linux/dma-mapping.h would need to include
> asm/dma-mapping.h which is what we're trying to avoid here.
We don't try to avoid that. You should at least make them sparc dma
mapping API noops for !CONFIG_PCI because it's assume you always
include the header - whether you can actually use the functionaly
depends on whether your bus supports this API.
On Tue, Jul 22, 2003 at 11:29:11PM -0700, David S. Miller wrote:
> On Wed, 23 Jul 2003 07:28:36 +0100
> Christoph Hellwig <[email protected]> wrote:
>
> > Putting it into linux/dma-mapping.h is fine with me, but I expect to
> > see more users of the dma-mapping API soon..
>
> And unlike this particular scsi layer usage, such drivers will be
> dependant upon things like CONFIG_PCI and thus won't get compiled
> in unless CONFIG_PCI has been enabled in the kernel configuration.
I originally though the whole idea was to remove the PCI dependency.
-solca
On Wed, 23 Jul 2003 07:40:33 +0100
Christoph Hellwig <[email protected]> wrote:
> On Tue, Jul 22, 2003 at 11:29:11PM -0700, David S. Miller wrote:
> > And unlike this particular scsi layer usage, such drivers will be
> > dependant upon things like CONFIG_PCI and thus won't get compiled
> > in unless CONFIG_PCI has been enabled in the kernel configuration.
>
> Umm, no. The whole idea of the DMA mapping API is that it's independant
> of the underlying bus. Think of usb or ieee1394 drivers doing direct DMA
> independant of the bus the underlying host adapter uses.
No USB or IEEE1394 on SBUS sparcs, so again no problem.
My point still holds, please put this enumeration into a truly generic
place that doesn't depend upon the actual implementation.
linux/dma-dir.h or even linux/device.h seem the most logical place (we
put the PCI ones in pci.h, and pci.h can be included cleanly even when
CONFIG_PCI is disabled, consider that), then we make
linux/dma-mapping.h and scsi/scsi_{cmnd,request}.h include this
linux/{device,dma-dir}.h file.
I don't see why this is a problem. Either do this, or fix
asm-generic/dma-mapping.h which is not GENERIC because it
depends upon something SPECIFIC, specifically PCI.
On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote:
> I don't see why this is a problem. Either do this, or fix
> asm-generic/dma-mapping.h which is not GENERIC because it
> depends upon something SPECIFIC, specifically PCI.
The latter is what need to be done.
On Wed, Jul 23, 2003 at 12:43:11AM -0600, Otto Solares wrote:
> I originally though the whole idea was to remove the PCI dependency.
There is no pci depency in the scsi core or drivers. The only
problem is that the dma-mapping.h implementation used by sparc
imposes an artifical PCI depency that needs to be removed.
If you want to help fix asm-generic/dma-mapping.h to be noops
if !CONFIG_PCI or even better make it always noops and add an
asm-generic/dma-mapping-in-terms-of-pci.h for those who want
them to map to PCI.
On Wed, 23 Jul 2003 08:02:22 +0100
Christoph Hellwig <[email protected]> wrote:
> On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote:
> > I don't see why this is a problem. Either do this, or fix
> > asm-generic/dma-mapping.h which is not GENERIC because it
> > depends upon something SPECIFIC, specifically PCI.
>
> The latter is what need to be done.
I'll do the following for now.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1518 -> 1.1519
# include/asm-sparc64/dma-mapping.h 1.1 -> 1.2
# include/asm-sparc/dma-mapping.h 1.1 -> 1.2
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/07/23 [email protected] 1.1519
# [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI.
# --------------------------------------------
#
diff -Nru a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
--- a/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003
+++ b/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003
@@ -1 +1,5 @@
+#include <linux/config.h>
+
+#ifdef CONFIG_PCI
#include <asm-generic/dma-mapping.h>
+#endif
diff -Nru a/include/asm-sparc64/dma-mapping.h b/include/asm-sparc64/dma-mapping.h
--- a/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003
+++ b/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003
@@ -1 +1,5 @@
+#include <linux/config.h>
+
+#ifdef CONFIG_PCI
#include <asm-generic/dma-mapping.h>
+#endif
On Wed, Jul 23, 2003 at 08:04:55AM +0100, Christoph Hellwig wrote:
> If you want to help fix asm-generic/dma-mapping.h to be noops
> if !CONFIG_PCI or even better make it always noops and add an
> asm-generic/dma-mapping-in-terms-of-pci.h for those who want
> them to map to PCI.
if !CONFIG_PCI -> noops
else include asm-generic/dma-mapping.h
That seems doable, but..
just arm, i386 & parisc have their own dma-mapping.h
everything else includes the generic one (pci dependant).
With this model what happens if a box had more than one
bus type (if technically possible)?
-solca
On Wed, 23 Jul 2003 01:20:56 -0600
Otto Solares <[email protected]> wrote:
> everything else includes the generic one (pci dependant).
> With this model what happens if a box had more than one
> bus type (if technically possible)?
If the architecture wants to support such situations,
then the implementation needs to vector off to different
operations based upon the actual bus type.
Even though technically devices having SBUS and PCI variants could do
this, none do currently, and also I do not use the generic device
model in the SBUS layer, therefore I'm not going to add such multi-bus
support to what Sparc uses for dma-mapping.h
If someone is bored and willing to do all of the generic device and
->dma_ops work for Sparc and SBUS, feel free to send me some patches.
Otherwise, it won't get done :-)
On Wed, 23 Jul 2003, David S. Miller wrote:
> If the architecture wants to support such situations,
> then the implementation needs to vector off to different
> operations based upon the actual bus type.
>
> Even though technically devices having SBUS and PCI variants could do
> this, none do currently, and also I do not use the generic device
> model in the SBUS layer, therefore I'm not going to add such multi-bus
> support to what Sparc uses for dma-mapping.h
Ouch - As I mentioned a few days ago, the Ex000 range can have a
mixture of SBUS and PCI. This configuration is becoming increasingly
common as these machines are upgraded to attach to SAN stuff and
other FCAL variants for which there is no SBUS card.
Please take a few moments to keep this, it works at the moment.
On Wed, 23 Jul 2003 09:33:40 +0100 (BST)
"C.Newport" <[email protected]> wrote:
> Ouch - As I mentioned a few days ago, the Ex000 range can have a
> mixture of SBUS and PCI.
So what?
> This configuration is becoming increasingly
> common as these machines are upgraded to attach to SAN stuff and
> other FCAL variants for which there is no SBUS card.
Nothing I have said prevents these systems from fully
working.
Because I won't move SBUS over to generic struct device,
none of the SBUS device drivers will change either, therefore
everything works as it does today.
What's the problem?
FYI i had compile both sparc32/sparc64 with these patch
and finally that fu**ing PCI dependency is gone! thank you :)
This should be done in asm-generic/dma-mapping.h IMHO with
others archs in mind.
-solca
On Wed, Jul 23, 2003 at 12:20:08AM -0700, David S. Miller wrote:
> On Wed, 23 Jul 2003 08:02:22 +0100
> Christoph Hellwig <[email protected]> wrote:
>
> > On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote:
> > > I don't see why this is a problem. Either do this, or fix
> > > asm-generic/dma-mapping.h which is not GENERIC because it
> > > depends upon something SPECIFIC, specifically PCI.
> >
> > The latter is what need to be done.
>
> I'll do the following for now.
>
> # This is a BitKeeper generated patch for the following project:
> # Project Name: Linux kernel tree
> # This patch format is intended for GNU patch command version 2.5 or higher.
> # This patch includes the following deltas:
> # ChangeSet 1.1518 -> 1.1519
> # include/asm-sparc64/dma-mapping.h 1.1 -> 1.2
> # include/asm-sparc/dma-mapping.h 1.1 -> 1.2
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 03/07/23 [email protected] 1.1519
> # [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI.
> # --------------------------------------------
> #
> diff -Nru a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
> --- a/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003
> +++ b/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003
> @@ -1 +1,5 @@
> +#include <linux/config.h>
> +
> +#ifdef CONFIG_PCI
> #include <asm-generic/dma-mapping.h>
> +#endif
> diff -Nru a/include/asm-sparc64/dma-mapping.h b/include/asm-sparc64/dma-mapping.h
> --- a/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003
> +++ b/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003
> @@ -1 +1,5 @@
> +#include <linux/config.h>
> +
> +#ifdef CONFIG_PCI
> #include <asm-generic/dma-mapping.h>
> +#endif
On Wed, Jul 23, 2003 at 12:27:37AM -0700, David S. Miller wrote:
> On Wed, 23 Jul 2003 01:20:56 -0600
> Otto Solares <[email protected]> wrote:
>
> > everything else includes the generic one (pci dependant).
> > With this model what happens if a box had more than one
> > bus type (if technically possible)?
>
> If the architecture wants to support such situations,
> then the implementation needs to vector off to different
> operations based upon the actual bus type.
>
> Even though technically devices having SBUS and PCI variants could do
> this, none do currently, and also I do not use the generic device
> model in the SBUS layer, therefore I'm not going to add such multi-bus
> support to what Sparc uses for dma-mapping.h
ok, i understand now. Theorically could be nice the new API,
i better stick with the current per-bus-drivers.
> If someone is bored and willing to do all of the generic device and
> ->dma_ops work for Sparc and SBUS, feel free to send me some patches.
> Otherwise, it won't get done :-)
:) fine with me.
-solca
On Wed, 23 Jul 2003, David S. Miller wrote:
> On Wed, 23 Jul 2003 09:33:40 +0100 (BST)
> "C.Newport" <[email protected]> wrote:
>
> > Ouch - As I mentioned a few days ago, the Ex000 range can have a
> > mixture of SBUS and PCI.
>
> So what?
>
> > This configuration is becoming increasingly
> > common as these machines are upgraded to attach to SAN stuff and
> > other FCAL variants for which there is no SBUS card.
>
> Nothing I have said prevents these systems from fully
> working.
>
> Because I won't move SBUS over to generic struct device,
> none of the SBUS device drivers will change either, therefore
> everything works as it does today.
>
> What's the problem?
In that case none, but your original message implied that this did
not exist and would not be supported.
Maybe I misunderstood what you meant.
OTOH, (if !SBUS) might screw up ?.
On Wed, 23 Jul 2003 10:35:56 +0100 (BST)
"C.Newport" <[email protected]> wrote:
> In that case none, but your original message implied that this did
> not exist and would not be supported.
>
> Maybe I misunderstood what you meant.
>
> OTOH, (if !SBUS) might screw up ?.
Look, SBUS does _NOT_ use the generic device abstraction.
Therefore all SBUS drivers call into the sbus_* DMA operations
directly.
Everything just works, as it always has, and it's not going to break
any time soon.
What I'm saying is that I'm not going to move the SBUS layer
over to use generic devices.
On Wed, 23 Jul 2003, David S. Miller wrote:
> On Wed, 23 Jul 2003 08:02:22 +0100
> Christoph Hellwig <[email protected]> wrote:
>
> > On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote:
> > > I don't see why this is a problem. Either do this, or fix
> > > asm-generic/dma-mapping.h which is not GENERIC because it
> > > depends upon something SPECIFIC, specifically PCI.
> >
> > The latter is what need to be done.
>
> I'll do the following for now.
>
> # This is a BitKeeper generated patch for the following project:
> # Project Name: Linux kernel tree
> # This patch format is intended for GNU patch command version 2.5 or higher.
> # This patch includes the following deltas:
> # ChangeSet 1.1518 -> 1.1519
> # include/asm-sparc64/dma-mapping.h 1.1 -> 1.2
> # include/asm-sparc/dma-mapping.h 1.1 -> 1.2
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 03/07/23 [email protected] 1.1519
> # [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI.
Yep, that's what I did for m68k as well (inspired by s390 which never has PCI
and thus an empty dma-mapping.h).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds