Re: HEADS UP: fxp breakage

2003-04-05 Thread Daniel C. Sobral
Daniel C. Sobral wrote: Maxime Henrion wrote: Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmle

Re: HEADS UP: fxp breakage

2003-04-05 Thread Daniel C. Sobral
Maxime Henrion wrote: Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmless unless you used DEVICE_PO

Re: HEADS UP: fxp breakage

2003-04-05 Thread Maxime Henrion
Hi all, I was finally able to reproduce the problems people have been reporting. That is, the fxp(4) card works but there are many odd "unknown: DMA timeout" and "unknown: device timeout" messages. This was due to a bug in fxp(4) which was harmless unless you used DEVICE_POLLING. These

RE: HEADS UP: fxp breakage

2003-04-05 Thread Robin P. Blanchard
Ok. Here's the information requested. This is taken from the boxes running a working, older kernel (otherwise wouldn't be able to get to them remotely). I can get the same info with the broken kernel come Monday should that be necessary. Hope this helps! 1) dell poweredge 4350 fxp0: flags=18843 m

HEADS UP: fxp breakage

2003-04-04 Thread Maxime Henrion
Hi all, Robin P. Blanchard wrote: > Following sources still yield unresponsive fxp interface. The same behavious > occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each > having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom. > > # fgrep -h \*\ \$FreeBSD

Fxp breakage (still)

2003-04-04 Thread Robin P. Blanchard
Following sources still yield unresponsive fxp interface. The same behavious occurs on both of my test boxes (dell 4350 and home-grown athlon xp), each having identical Intel Pro 100+M nics with v4.1.0.9 intel PXE rom. # fgrep -h \*\ \$FreeBSD /usr/src/sys/dev/fxp/* * $FreeBSD: src/sys/dev/fxp/i

Fxp breakage

2003-04-03 Thread Robin P. Blanchard
Ok. Hopefully some useful information hereUsing a kernel built against the below fxp sources, the interface simply does not pass or see any traffic. Reverting back to kernel from 01 April permits the intrace to function properly. fxp0: flags=18843 mtu 1500 inet 10.10.10.201 netmask 0xf

Re: FXP breakage

2003-04-03 Thread Chuck McCrobie
--- Pete Carah <[EMAIL PROTECTED]> wrote: > This may be just my infamous vaio acting up again, > but since the > recent commit to fxp driver (Monday?) I get a panic > on device probe > (page fault in kernel mode). > > That and the way the pccbb act up (always return 0 > for event and > status re

Re: FXP breakage

2003-04-03 Thread Maxime Henrion
Pete Carah wrote: > This may be just my infamous vaio acting up again, but since the > recent commit to fxp driver (Monday?) I get a panic on device probe > (page fault in kernel mode). This should be fixed in revision 1.30 of if_fxpreg.h that I committed some time ago. Sorry for the inconvenien

FXP breakage

2003-04-03 Thread Pete Carah
This may be just my infamous vaio acting up again, but since the recent commit to fxp driver (Monday?) I get a panic on device probe (page fault in kernel mode). That and the way the pccbb act up (always return 0 for event and status register reads, and don't reset pending interrupt on event reg