Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Oct 2001 07:30:01 -0700 (PDT)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: i386/30965: Cyclades Cyclom-Yep causes FreeBSD to hang during
Message-ID:  <200110251430.f9PEU1V31712@freefall.freebsd.org>

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: Bruce Evans <bde@zeta.org.au>
To: Arjan Knepper <arjan@jak.nl>
Cc: <klemscot@klements.com>, <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: i386/30965: Cyclades Cyclom-Yep causes FreeBSD to hang during
Date: Fri, 26 Oct 2001 00:20:27 +1000 (EST)

 On Thu, 25 Oct 2001, Arjan Knepper wrote:
 
 > >From: Scott Klement <klemscot@klements.com>
 > >Date: Mon, 22 Oct 2001 01:16:27 -0500 (CDT)
 > >
 > > On Sun, 21 Oct 2001, Bruce Evans wrote:
 > > > 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?
 
 It does seem like the same problem for 1 board.
 
 > Already tried the -CURRENT, dind't help me.
 
 > 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>---------------------------------------------------------------------
 
 Sorry I didn't reply to this before.
 
 I think it locks up here just because this enables the interrupt, an
 interrupt occures immediately, and interrupt handling never completes.
 You could try putting printfs in the interrupt handler (cyintr()).
 Or using ddb, put breakpoints at interesting places in the interrupt
 handler and see if they are hit.  The initial interesting places are
 the start of the interrupt handler (cyintr()) and when it returns (get
 the return address using a trace command).
 
 > > Attached my kernel conf file and below the piece of code containg the
 > > lines.
 > >...
 > >        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;
 > >        }
 > >...
 > BTW Linux redhat 7.1 runs just fine on this system with 3 Cyclades PCI
 > boards.
 
 The corresponding code in Linux has interesting similarities and
 differences.
 
 %                 /* enable interrupts in the PCI interface */
 % 		plx_ver = cy_readb(cy_pci_addr2 + CyPLX_VER) & 0x0f;
 % 		switch (plx_ver) {
 % 		    case PLX_9050:
 %
 % 		    cy_writeb(cy_pci_addr0+0x4c, 0x43);
 % 		    break;
 %
 % 		    case PLX_9060:
 % 		    case PLX_9080:
 % 		    default: /* Old boards, use PLX_9060 */
 %
 % 		    plx_init(cy_pci_addr0, 0x6c);
 % 		    /* For some yet unknown reason, once the PLX9060 reloads
 % 		       the EEPROM, the IRQ is lost and, thus, we have to
 % 		       re-write it to the PCI config. registers.
 % 		       This will remain here until we find a permanent fix. */
 % 		    pci_write_config_byte(pdev, PCI_INTERRUPT_LINE, cy_pci_irq);
 %
 % 		    cy_writew(cy_pci_addr0+0x68,
 % 			cy_readw(cy_pci_addr0+0x68)|0x0900);
 % 		    break;
 
 Differences:
 - for the PLX_9050 case, the magic number 0x43 is spelled non-magically
   in FreeBSD, and has a different value (0x41).
 - for the other cases, FreeBSD doesn't do the plx_init() or the IRQ reload
   hack.
 
 Thes differences may be related to the following commits in the Linux
 driver:
 
 %  * Revision 2.3.2.6   2000/05/05 13:56:05 ivan
 %  ...
 %  * Implemented workaround for PLX9050 bug that would cause a system lockup
 %  * in certain systems, depending on the MMIO addresses allocated to the
 %  * board.
 %  * ...
 %  * Revision 2.2.1.9  1998/12/30 18:18:30 ivan
 %  * Changed access to PLX PCI bridge registers from I/O to MMIO, in
 %  * order to make PLX9050-based boards work with certain motherboards.
 %  ...
 %  * Revision 2.2.2.3   1999/06/28 11:13:29 ivan
 %  ...
 %  * Implemented workaround for IRQ setting loss on the PCI configuration
 %  * registers after a PCI bridge EEPROM reload (affects PLX9060 only);
 
 You could try the 0x41 -> 0x43 change easily.  Unfortunately, I don't
 have docs for any of this.  I have corresponded with ivan@cyclades.com,
 but not for 2.5 years.
 
 Bruce
 

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?200110251430.f9PEU1V31712>