Date: Wed, 01 Oct 1997 12:45:27 -0600 From: "Mike Durian" <durian@plutotech.com> To: hackers@freebsd.org Subject: strange interaction with Pentium and fxp Message-ID: <199710011845.MAA19255@pluto.plutotech.com>
next in thread | raw e-mail | index | archive | help
I've been chatting with David Greenman about this problem I'm seeing, but since we've determined it's not really a fxp driver bug, I'd like to get some input from a wider audience. When I boot single user and ifconfig fxp0 I get a PCI bus failure with a new -current kernel, but don't with an old kernel. The nature of the PCI bus failure is that the 430fx chipset never asserts TRDY# for the read mem multiple command issued by the EtherExpress as part of its very first DMA. Eventually the command times out, the PCI cards (including the EtherExpress) get confused by the invalid PCI command and start throwing interrupts that aren't normally checked for in the interrupt handler, thus locking up the system. So I need to figure out why TRDY# isn't getting asserted with the new kernel. I've got traces of both a working instance of this first mem read multiple from an old kernel and one that fails with the new kernel. The only difference I can detect is that the old kernel stores the mbuf at a physical address like 0x2bxx54 and the new one has the mbuf at 0x3f54 - a much lower memory address. I should also mention that this problem does not occur on a Pentium Pro system. I have not stuck my PCI bus analyzer on the P6 machine, so I'm not positive it uses the same addresses, but I'm assuming it would. This could very well be a 430FX chipset bug, but I still need a work around. I have not yet verified that this problem exists on a different Pentium system, so it is possible that it is specific to the motherboard. Does anyone have any ideas? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710011845.MAA19255>