Date: Sat, 13 Sep 2003 08:19:50 +1000 From: John Birrell <jb@cimlogic.com.au> To: John Polstra <jdp@polstra.com> Cc: freebsd-stable@freebsd.org Subject: Re: recent stability problems with fxp driver Message-ID: <20030912221950.GA84689@freebsd1.cimlogic.com.au> In-Reply-To: <XFMail.20030912135156.jdp@polstra.com> References: <6.0.0.22.0.20030912134112.05891060@209.112.4.2> <XFMail.20030912135156.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 12, 2003 at 01:51:56PM -0700, John Polstra wrote: > The problem is real, at least on some hardware. I had to give up on > using the two integrated fxp devices on my Dell 1550 -- which is a > real bummer, since it's a 1U box that only has two PCI slots. With > the latest -stable driver, I couldn't fetch a 560 MB file from > another machine on the LAN using FTP without killing the fxp device. I'm suffering what seem like different problems with the fxp driver. In RELENG_4 the driver works well on two different embedded boards that I have. On one of those boards I regularly transfer ~500 MB files [via HTTP 8-)] and the driver appears stable. As soon as I try to run -current on one of those boards, the kernel hangs in fxp's attach, just after the IRQ resource is allocated, and possibly just when the driver tries to reset the board. I haven't been able to debug this. I wonder if the device is creating an interrupt storm. I have a hard time believing that the BIOS is behaving any differently when booting a RELENG_4 kernel compared to a current one. Certainly the probe output for fxp is the same. When I try the same -current kernel on the other embedded board, it works. The boards are very different. One has a Cyrix processor and the other is an AMD Elan SC520. They both have a General Software bios, but obviously the different processors make that largely irrelevant. What makes my situation even more confusing is that the -current kernel that hangs attaching fxp, was actually netbooted over the device that it hangs attaching. I'm tempted to conclude that it isn't rogue hardware - just a situation that isn't catered for FreeBSD. I wish I knew how to debug it. -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030912221950.GA84689>