Date: Thu, 20 Nov 1997 23:07:08 -0500 (EST) From: "John W. DeBoskey" <jwd@unx.sas.com> To: dg@root.com Cc: freebsd-current@freebsd.org Subject: Re: fxp0 causes machine lockup Message-ID: <199711210407.AA10760@iluvatar.unx.sas.com> In-Reply-To: <199711180936.BAA12735@implode.root.com> from "David Greenman" at Nov 18, 97 01:36:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
With respect to the following problem, the solution came from
an unexpected location.
I asked our hardware support folks for a 2nd motherboard to see
if the problem was specific to the hardware. Before getting the
new MB, they suggested I upgrade the bios on my machine... I said
sure, thinking FreeBSD doesn't use the bios, what could happen?
Dell OptiPlex PPro 200 with bios rev A00(Phoenix) flashed to A08.
The problem went away.
Could someone give me a short explanation of how the bios update
could fix my apparent dma problem? Does the bios assign dma channels
or something associated?
Anyways, I have now tested rev 0, 2, & 4 fxp NICs with complete
success.
Thanks!
John
ps: I'm going to try using the kernel debugger to make sure that
part of the following problem went away also...
>
> >in /sys/pci/if_fxp.c the following fragment from fxp_init()
> >appears to be the problem:
> >
> > /*
> > * Start the config command/DMA.
> > */
> > fxp_scb_wait(sc);
> > CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(cbp));
> > CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND, FXP_SCB_COMMAND_CU_START);
> > /* ...and wait for it to complete. */
> > while (!(cbp->cb_status & FXP_CB_STATUS_C));
> >
> > The fxp_scb_wait, CSR_WRITE_4 and CSR_WRITE_1 calls (appear to)
> >work correctly. What I cannot find is the location in the code where
> >the FXP_CB_STATUS_C bit is set in a (interrupt?) routine. Nor can I
> >break into DDB at this point.
>
> The "FXP_CB_STATUS_C" flag is set by the Pro/100B DMA engine when the
> processing of the command descriptor has completed. Network interrupts are
> disabled at that point, so none are expected. I would guess that it is
> hanging when DMA is started and not in the while loop after it.
> I noticed this:
>
> >fxp0: <Intel EtherExpress Pro 10/100B Ethernet> rev 0x04 int a irq 14 on pci1.9.0
> >fxp0: Ethernet address 00:a0:c9:8b:09:a5
>
> "rev 0x04"...hmmm. I haven't see a rev that high on the 82557 - perhaps
> your card is an 82558 based Pro/100+? That should still work just fine, but
> I haven't specifically tested it in FreeBSD.
>
> >built and installed the new kernel. When rebooting, I specified the
> >-d option to bring up the kernel debugger. I then specified:
> >
> >b fxp_init
> >c
> >
> > and the system panic'd in the bounce buffer code saying it could not
> >malloc enough memory.. Ok, well, I don't need bounce buffers on my
> >machine, so I removed options BOUNCE_BUFFERS from GENERIC and once
> >again rebuilt & installed. Again I rebooted and specified -d and
> >issued the break & continue commands.
> >
> > This time, a series of "Could not malloc" messages went by, but
> >none stopped the system. Finally, it got to the point where is wanted
> >to mount the root filesystem. It said it could not mount the root
> >filesystem and hung.
>
> Strange. I can't explain that, but I'd say it was indicating something
> seriously bad happened. Did you remove any other options or make any other
> changes to the config file? Does the new kernel boot without the "-d"?
>
> -DG
>
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project
>
--
jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711210407.AA10760>