Bug 24177

You don't say which specific platform this is. It's unusual that I/O space
works better than Memory space. It's also true that various flavors of EEPRO
are known to work.

I sure wish I knew whether the maintainer for this card s active or not on
this. I think your patches are in the right direction, but aren't really quite
what we should be looking for- they could be a lot tighter and should be
runtime as opposed to compile time settable- see isp_pci.c for an example (not
the best, granted) of this.

I sure would like to know which platform this was.

-matt


> 
> >Number:         24177
> >Category:       alpha
> >Synopsis:       Workaround patch for fxp on Alpha
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    freebsd-alpha
> >State:          open
> >Quarter:        
> >Keywords:       
> >Date-Required:
> >Class:          change-request
> >Submitter-Id:   current-users
> >Arrival-Date:   Tue Jan 09 02:10:01 PST 2001
> >Closed-Date:
> >Last-Modified:
> >Originator:     Kees Jan Koster
> >Release:        FreeBSD 4.2-RC1 alpha
> >Organization:
> >Environment:
> 
> FreeBSD slugout.kjkoster.org 4.2-RC1 FreeBSD 4.2-RC1 #1: Sat Jan  6 16:34:31 CET 2001     root@:/usr/src/sys/compile/SLUGOUT  alpha
> 
> >Description:
> 
> The current fxp driver does not see some of the cards. In particular it does
> not see mine (Asus L101 card). It probes af follows:
> 
> Jan  6 12:06:08  /kernel: fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0
> Jan  6 12:06:08  /kernel: fxp0: interrupting at ISA irq 5  
> Jan  6 12:06:08  /kernel: fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps
> 
> After the workaround that someone suggested (I plucked it off freebsd-alpha a
> while ago) the card probes as follows:
> 
> Jan  6 19:39:04  /kernel: fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0
> Jan  6 19:39:04  /kernel: fxp0: using i/o space access
> Jan  6 19:39:04  /kernel: fxp0: interrupting at ISA irq 5
> Jan  6 19:39:04  /kernel: fxp0: Ethernet address 00:e0:18:00:2b:98
> 
> I realize that the workaround is not a complete fix. However, the current state
> of affairs means that I cannot install FreeBSD/alpha without special tricks. I
> was hoping that this workaround might be put into the kernel anyway, with
> proper warning comments.
> 
> >How-To-Repeat:
> 
> Use an fxp-driven card in an Alpha.
> 
> >Fix:
> 
> Index: if_fxp.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v
> retrieving revision 1.77.2.6
> diff -u -r1.77.2.6 if_fxp.c
> --- if_fxp.c    2000/07/19 14:36:36     1.77.2.6
> +++ if_fxp.c    2000/07/25 18:53:08
> @@ -515,6 +515,8 @@
>         return ENXIO;
>  }
>  
> +#define FXP_PREFER_IOSPACE
> +
>  static int
>  fxp_attach(device_t dev)
>  {
> @@ -533,12 +535,31 @@
>          * Enable bus mastering.
>          */
>         val = pci_read_config(dev, PCIR_COMMAND, 2);
> +#ifdef FXP_PREFER_IOSPACE       /*XXX*/
> +       val |= (PCIM_CMD_PORTEN|PCIM_CMD_BUSMASTEREN);
> +#else
>         val |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN);
> +#endif
>         pci_write_config(dev, PCIR_COMMAND, val, 2);
>  
>         /*
>          * Map control/status registers.
>          */
> +#ifdef FXP_PREFER_IOSPACE       /*XXX*/
> +       device_printf(dev, "using i/o space access\n");
> +       rid = FXP_PCI_IOBA;
> +       sc->io = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid,
> +                                    0, ~0, 1, RF_ACTIVE);
> +       if (!sc->io) {
> +               device_printf(dev, "could not map memory\n");
> +               error = ENXIO;
> +               goto fail;
> +        }
> +
> +       sc->sc_st = rman_get_bustag(sc->io);
> +       sc->sc_sh = rman_get_bushandle(sc->io);
> +
> +#else
>         rid = FXP_PCI_MMBA;
>         sc->mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid,
>                                      0, ~0, 1, RF_ACTIVE);
> @@ -550,7 +571,7 @@
>  
>         sc->sc_st = rman_get_bustag(sc->mem);
>         sc->sc_sh = rman_get_bushandle(sc->mem);
> -
> +#endif
>         /*
>          * Allocate our interrupt.
>          */
> @@ -575,7 +596,11 @@
>                 /* Failed! */
>                 bus_teardown_intr(dev, sc->irq, sc->ih);
>                 bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq);
> +#ifdef FXP_PREFER_IOSPACE /* XXX */
>                 bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem);
> +#else
> +               bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io);
> +#endif
>                 error = ENXIO;
>                 goto fail;
>         }
> @@ -639,8 +664,11 @@
>          */
>         bus_teardown_intr(dev, sc->irq, sc->ih);
>         bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq);
> +#ifdef FXP_PREFER_IOSPACE /* XXX */
> +       bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io);
> +#else
>         bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem);
> -
> +#endif
>         /*
>          * Free all the receive buffers.
>          */
> Index: if_fxpvar.h
> ===================================================================
> RCS file: /home/ncvs/src/sys/pci/if_fxpvar.h,v
> retrieving revision 1.9.2.1
> diff -u -r1.9.2.1 if_fxpvar.h
> --- if_fxpvar.h 2000/03/29 02:02:39     1.9.2.1
> +++ if_fxpvar.h 2000/07/25 18:28:23
> @@ -46,6 +46,7 @@
>  #else
>         struct arpcom arpcom;           /* per-interface network data */
>         struct resource *mem;           /* resource descriptor for registers */
> +       struct resource *io;            /* resource descriptor for registers */
>         struct resource *irq;           /* resource descriptor for interrupt */
>         void *ih;                       /* interrupt handler cookie */
>  #endif /* __NetBSD__ */
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-alpha" in the body of the message
>

>
> You don't say which specific platform this is. It's unusual that I/O space
> works better than Memory space. It's also true that various flavors of EEPRO
> are known to work.
>
D'oh! I keep forgetting Alpha's aren't PC's. :) Here's the relevant
dmesg snippet.

  DEC AXPpci
  Alpha PC AXPpci33, 166MHz
  8192 byte page size, 1 processor.
  CPU: LCA Family major=4 minor=2
  OSF PAL rev: 0x100090002012d

I apologize for not including this information immediately.

> 
> I sure wish I knew whether the maintainer for this card s active or not on
> this. I think your patches are in the right direction, but aren't really quite
> what we should be looking for- they could be a lot tighter and should be
> runtime as opposed to compile time settable- see isp_pci.c for an example (not
> the best, granted) of this.
>
These are not my own patches. I reported this problem earlier on
freebsd-alpha and in the resulting discussion these patches came up. I
tried them and they worked for me. The discussion was in the "fxp0 hangs
on a PC164 using STABLE" and the "fxp0 hangs my AXPpci33" threads, on
freebsd-alpha around July 2000.

At the time they were not committed because of their hackish nature, as
you have noted yourself. Someone hinted that he was going to rework them
in a more socially acceptable manner, but his time seems to have been
claimed by more important matters. Since this was months ago I figured
that I should try to get the patch committed.

  Yours,
    Kees Jan

 ------------------------------------------------------------------
  Kees Jan Koster             e-mail: dutchman "at" tccn.cs.kun.nl
                              www:        http://www.kjkoster.org/
 ------------------------------------------------------------------
  You're only young once, but you can stay immature all your life.

On Tue, 9 Jan 2001, Kees Jan Koster wrote:

> >
> > You don't say which specific platform this is. It's unusual that I/O space
> > works better than Memory space. It's also true that various flavors of EEPRO
> > are known to work.
> >
> D'oh! I keep forgetting Alpha's aren't PC's. :) Here's the relevant
> dmesg snippet.
> 
>   DEC AXPpci
>   Alpha PC AXPpci33, 166MHz
>   8192 byte page size, 1 processor.
>   CPU: LCA Family major=4 minor=2
>   OSF PAL rev: 0x100090002012d
> 
> I apologize for not including this information immediately.

No, that's fine... I just needed to know. 

You know, I'd forgotten about LCA- that probably is the only PCI chipset for
alphas where I/O space is more functional than Memory space.

> 
> > 
> > I sure wish I knew whether the maintainer for this card s active or not on
> > this. I think your patches are in the right direction, but aren't really quite
> > what we should be looking for- they could be a lot tighter and should be
> > runtime as opposed to compile time settable- see isp_pci.c for an example (not
> > the best, granted) of this.
> >
> These are not my own patches. I reported this problem earlier on
> freebsd-alpha and in the resulting discussion these patches came up. I
> tried them and they worked for me. The discussion was in the "fxp0 hangs
> on a PC164 using STABLE" and the "fxp0 hangs my AXPpci33" threads, on
> freebsd-alpha around July 2000.
> 
> At the time they were not committed because of their hackish nature, as
> you have noted yourself. Someone hinted that he was going to rework them
> in a more socially acceptable manner, but his time seems to have been
> claimed by more important matters. Since this was months ago I figured
> that I should try to get the patch committed.

Was the driver author gonna do this? Who? Yes, it should be done. I could
probably even get to it myself- but not if somebody else is on it.

-matt

> 
> You know, I'd forgotten about LCA- that probably is the only PCI chipset for
> alphas where I/O space is more functional than Memory space.
>
At the very least for my card. :-)

> 
> Was the driver author gonna do this? Who? Yes, it should be done. I could
> probably even get to it myself- but not if somebody else is on it.
> 
I don't know. The author is David Greenman <dg@root.com>, I will ask
him.

  Yours,
    Kees Jan

 ------------------------------------------------------------------
  Kees Jan Koster             e-mail: dutchman "at" tccn.cs.kun.nl
                              www:        http://www.kjkoster.org/
 ------------------------------------------------------------------
  You're only young once, but you can stay immature all your life.

Comment 5 wilko 2001-01-24 18:03:40 UTC

State Changed
From-To: open->closed