It seems recent current doesn't like my fxp. A current from some 10
hours ago keeps complaining about device timeout and dma timeout. I
don't *know* it's fxp fault (for one thing, because it says unknown),
but...
So, two hours ago, I cvsupped and tried a new world. This one panics on
boot,
Daniel C. Sobral wrote:
It seems recent current doesn't like my fxp. A current from some 10
hours ago keeps complaining about device timeout and dma timeout. I
don't *know* it's fxp fault (for one thing, because it says unknown),
but...
So, two hours ago, I cvsupped and tried a new
Peter Wemm wrote:
Daniel C. Sobral wrote:
It seems recent current doesn't like my fxp. A current from some 10
hours ago keeps complaining about device timeout and dma timeout. I
don't *know* it's fxp fault (for one thing, because it says unknown),
but...
So, two hours ago, I cvsupped and
Daniel C. Sobral wrote:
Peter Wemm wrote:
Daniel C. Sobral wrote:
It seems recent current doesn't like my fxp. A current from some 10
hours ago keeps complaining about device timeout and dma timeout. I
don't *know* it's fxp fault (for one thing, because it says unknown),
but...
So,
I'm seeing the same thing. A kernel from first thing this morning paniced the
kernel whilst attempting to probe the device. I saw a commit go in shortly
after 15.00 and rebuilt the kernel. Kernel built on that commit allows the
box to boot, but the device simply doesn't pass (or see) any
On Thu, Apr 03, 2003 at 04:10:04PM -0500, Robin P. Blanchard wrote:
# ls -ltr /usr/src/sys/dev/fxp/
total 116
-rw-r--r-- 1 root wheel 21318 Oct 25 2001 rcvbundl.h
-rw-r--r-- 1 root wheel 8190 Apr 2 13:00 if_fxpvar.h
-rw-r--r-- 1 root wheel 73326 Apr 3 11:46 if_fxp.c
-rw-r--r--
Jonathan Lemon writes:
Please consider the case where there are two mbuf chains being
transmitted, which look like this:
Um. Not Possible.
I thought m_copypacket() of a cluster mbuf would yield exactly
this situation (two headers pointing to the same data region).
-Arcihe
On Sat, May 05, 2001 at 04:04:27PM -0700, Archie Cobbs wrote:
Jonathan Lemon writes:
Please consider the case where there are two mbuf chains being
transmitted, which look like this:
Um. Not Possible.
I thought m_copypacket() of a cluster mbuf would yield exactly
this situation
] I would be quite interested in knowing just how you manage
] to accomplish that, given that all the transmit control buffers
] are arranged in a circular linked list:
]
] fxp_init(void *xsc)
] {
] ...
] for (i = 0; i FXP_NTXCB; i++) {
] ...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
] I would be quite interested in knowing just how you manage
] to accomplish that, given that all the transmit control buffers
] are arranged in a circular linked list:
]
] fxp_init(void *xsc)
] {
] ...
]
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
I'm updating a machine (Pentium II 350, 128MB RAM) to -current, and ran
into this panic in the fxp driver. Sources are from today (5/1/2001).
I believe the chip is an 82557.
I compiled and installed a kernel, rebooted and started running an
installworld over NFS. The installworld stopped here
Kenneth D. Merry wrote:
It looks like the mbuf pointer is bogus:
(kgdb) print m
$2 = (struct mbuf *) 0xf0006b00
(kgdb) print *m
Cannot access memory at address 0xf0006b00.
Although in the next frame up the stack, the mbuf pointer looks okay:
(kgdb) up
#1 0xc018ef76 in fxp_intr
On Tue, May 01, 2001 at 02:16:33PM -0700, Peter Wemm wrote:
On the other hand,
you might try using dwarf2 debugging, that is pretty complete.
And what we'll be using when GCC 3.0 is imported.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
I've been working for a while to try to figure out a problem I'm having
here.
I did a buildworld Sunday, and started to get kernel panics on boot when
it probed fxp. So I removed fxp from my kernel and loaded it as a
module (via loader.conf.local). It paniced. Then I unloaded the
if_fxp.ko on
PLEASE read this:
http://www.freebsd.org/FAQ/hackers.html#AEN4885
Basically, by just looking at the page fault message, this appears to
be the dereferencing of a NULL pointer. That's all that I'm afraid pretty
much anybody will be able to conclude from this unless
17 matches
Mail list logo
