Date: Thu, 25 Oct 2001 10:53:51 +0200 From: Arjan Knepper <arjan@jak.nl> To: klemscot@klements.com, bde@zeta.org.au, freebsd-bugs@FreeBSD.org Subject: Re: i386/30965: Cyclades Cyclom-Yep causes FreeBSD to hang during Message-ID: <3BD7D31F.6050006@jak.nl>
next in thread | raw e-mail | index | archive | help
>
>
>The following reply was made to PR i386/30965; it has been noted by GNATS.
>
>From: Scott Klement <klemscot@klements.com>
>To: Bruce Evans <bde@zeta.org.au>
>Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>
>Subject: Re: i386/30965: Cyclades Cyclom-Yep causes FreeBSD to hang during
> boot
>Date: Mon, 22 Oct 2001 01:16:27 -0500 (CDT)
>
> On Sun, 21 Oct 2001, Bruce Evans wrote:
>
> > On Fri, 19 Oct 2001, Scott Klement wrote:
> >
> > > The BIOS does not show any IRQ conflicts. The dmesg also does not show any
> > > IRQ conflicts. (But perhaps something is responding on IRQs that it
> > > shouldnt? I wish I knew more about how this works...)
> >
> > Do you mean it desn't show any shared IRQs? PCI IRQs can't really conflict.
> > Shareing them is supposed to work.
> >
>
> Errr.. sorry, you're right. I meant that no two devices are assigned the
> same IRQ number -- i.e. nothing is shared.
>
> I have to disable devices to get it to that point, where nothing is
> shared, but doing so does not prevent FreeBSD from hanging during boot.
>
I have the same kind of trouble, are you using 1 cy board?
>> > I can certainly send you a dmesg if that will help. I could also send
> > > the e-mail conversation that I had with the Tech Support person at
> > > Cyclades about this.. would that help?
> >
> > Start with the complete dmesg for booting with -v, and "pciconf -lv"
> > output.
>
> I can do the dmesg by using a serial console, and recording the output
> with script(1) or similar... But I can't really do a pciconf, since
> the FreeBSD hangs before I can get to a shell prompt.
>
> Unless, of course, running pciconf without the Cyclades equipment attached
> would help?
>
> Also, the pciconf in 4.4R doesn't appear to have a -v option. Perhaps
> I should upgrade to -current before trying these things. I'll begin
> the upgrade process as soon as I can Monday morning... It's a fast
> machine, so making world shouldn't be too bad.
>
Already tried the -CURRENT, dind't help me.
>
> > Did the Tech Support seem helpful?
>
> They were courteous, and treated me with respect -- making them the best
> tech support I've ever worked with :) But, they didn't suggest anything
> that I hadn't already thought of or tried.
>
<g>
I did send them a complete report about how and what, and they simply
replyed : "sorry we don't have anyone around with FreeBSD knowledge and
we don't have FreeBSD test systems. Did you run MAKEDEV for the cyclades
devices?"
Bellow an email to -HACKERS with some test results:
> Hello,
>
> There are problems with the Cyclades Cyclom YeP driver. (see PR
> i386/30965). I've put printf's in the driver code on several places to
> check where the point is of hard locking and its seems to be on line
> 136 in the /usr/src/sys/pci/cy_pci.c in my situation.
>
> --------<snipped>---------------------------------------------------------------------
>
> case PLX_9050:
> outw(ioport + CY_PLX_9050_ICS,
> inw(ioport + CY_PLX_9050_ICS) |
> CY_PLX_9050_ICS_IENABLE |
> CY_PLX_9050_ICS_LOCAL_IENABLE);
> --------<snipped>---------------------------------------------------------------------
>
> This particular piece of code is hard-locking a DUAL PENTIUM III 933
> DELL PowerEdge 2550 with 2 YeP (PCI) boards with a SINGLE CPU kernel.
> (Doesn't even react on numlock key anymore)
>
> I really need some enligtment on this.
>
> Attached my kernel conf file and below the piece of code containg the
> lines.
>
> static void
> cy_attach(config_id, unit)
> pcici_t config_id;
> int unit;
> {
> vm_offset_t paddr;
> void *vaddr;
> u_int32_t ioport;
> int adapter;
> u_char plx_ver;
>
> ioport = (u_int32_t) pci_conf_read(config_id,
> CY_PCI_BASE_ADDR1) & ~0x3;
> paddr = pci_conf_read(config_id, CY_PCI_BASE_ADDR2) & ~0xf;
> #if 0
> if (!pci_map_mem(config_id, CY_PCI_BASE_ADDR2, &vaddr, &paddr)) {
> printf("cy%d: couldn't map shared memory\n", unit);
> return;
> };
> #endif
> vaddr = pmap_mapdev(paddr, 0x4000);
>
> adapter = cyattach_common(vaddr, 1);
> if (adapter < 0) {
> /*
> * No ports found. Release resources and punt.
> */
> printf("cy%d: no ports found!\n", unit);
> goto fail;
> }
>
> /*
> * Allocate our interrupt.
> * XXX Using the ISA interrupt handler directly is a bit of a
> violation
> * since it doesn't actually take the same argument. For
> PCI, the
> * argument is a void * token, but for ISA it is a unit.
> Since
> * there is no overlap in PCI/ISA unit numbers for this
> driver, and
> * since the ISA driver must handle the interrupt anyway,
> we use
> * the unit number as the token even for PCI.
> */
> if (
> #ifdef CY_PCI_FASTINTR
> !pci_map_int_right(config_id, (pci_inthand_t *)cyintr,
> (void *)adapter, &tty_imask,
> INTR_EXCL | INTR_FAST) &&
> #endif
> !pci_map_int_right(config_id, (pci_inthand_t *)cyintr,
> (void *)adapter, &tty_imask, 0)) {
> printf("cy%d: couldn't map interrupt\n", unit);
> goto fail;
> }
>
> /*
> * Enable the "local" interrupt input to generate a
> * PCI interrupt.
> */
> plx_ver = *((u_char *)vaddr + PLX_VER) & 0x0f;
> switch (plx_ver) {
> case PLX_9050:
> outw(ioport + CY_PLX_9050_ICS,
> inw(ioport + CY_PLX_9050_ICS) |
> CY_PLX_9050_ICS_IENABLE |
> CY_PLX_9050_ICS_LOCAL_IENABLE);
> break;
> case PLX_9060:
> case PLX_9080:
> default: /* Old board, use PLX_9060 values. */
> outw(ioport + CY_PLX_9060_ICS,
> inw(ioport + CY_PLX_9060_ICS) |
> CY_PLX_9060_ICS_IENABLE |
> CY_PLX_9060_ICS_LOCAL_IENABLE);
> break;
> }
>
> return;
>
> fail:
> /* XXX should release any allocated virtual memory */
> return;
> }
>
BTW Linux redhat 7.1 runs just fine on this system with 3 Cyclades PCI
boards.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BD7D31F.6050006>