On Wed, 26 Sep 2001, mark tinguely wrote:
There is nothing like raising a topic that was last seen several months
ago, but ...
Has there been any serious consideration to committing the arcnet code
that mentioned on 20 Jul 2001 (http://iclub.nsu.ru/~fjoe/arcnet/)?
I guess I should ask if
hi, there!
On Wed, Sep 26, 2001 at 12:59:01PM -0500, mark tinguely wrote:
There is nothing like raising a topic that was last seen several months
ago, but ...
Has there been any serious consideration to committing the arcnet code
that mentioned on 20 Jul 2001
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
I just wanted to say that you did a hell of a job with the csum
offload stuff in FreeBSD. FreeBSD is the only OS that I'm aware of
which allows a driver to choose not to handle csum'ing IP frags on
transmit. Having the option to not handle frags
On Wed, Sep 26, 2001 at 12:59:01PM -0500, mark tinguely wrote:
There is nothing like raising a topic that was last seen several months
ago, but ...
Has there been any serious consideration to committing the arcnet code
that mentioned on 20 Jul 2001
On Sunday, 23rd September 2001, Poul-Henning Kamp wrote:
Things to look out for:
1. !ufs filesystems
I am irredeemably slack for not testing this a lot but...
I believe I saw bad interactions between vmiodirenable and isofs on 4.3-R.
I mounted a CD, looked at stuff on it, did a lot of other
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather capability doesn't pick
up what was intended,
Ronald G Minnich writes:
I have a question on the checksum offloading. Has anyone measured any
incidence of data corruption between the PCI card and memory. In other
words, when you offload checksums the end-to-end checking becomes
card-to-card checking, and the possibility exists that
Louis A. Mamakos writes:
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather capability
Hi, I tried to rebuilt my kernel with device rl0
(NIC PLANET ENW-9503A based on REALTEK 8139 chip) it has collapsed during make
phase. It cannot find files starting with mii* but they are
present.
Thank you
Im runnign FreeBSD
4.4(Amnesiac)
Hi, I tried to rebuilt my kernel with device rl0
(NIC PLANET ENW-9503A based on REALTEK 8139 chip) it has collapsed during make
phase. It cannot find files starting with mii* but they are
present.
Thank you
Im runnign FreeBSD
4.4(Amnesiac)
On Thu, Sep 27, 2001 at 04:44:31PM +0200, Martin Vana wrote:
Hi, I tried to rebuilt my kernel with device rl0 (NIC PLANET ENW-9503A based on
REALTEK 8139 chip) it has collapsed during make phase. It cannot find files starting
with mii* but they are present.
Is it that it cannot find the
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
No, you're missing the point almost entirely. The checksum is not
skipped. It is calculated by the DMA engine based on the data that's
transferred across the I/O bus on the receiver (and / or the sender).
If the data is incorrect as seen by the
It certainly occurs at a rate to worry one. Alan Poston found definite cases
of corruption when doing heavy IDE testing. It varies, motherboard to
motherboard.
On Thu, 27 Sep 2001, Ronald G Minnich wrote:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
I just wanted to say that you did a
Ronald G Minnich writes:
you still have a potential problem here with variance in chipsets, namely
the case of broken ABORT or other unusual PCI cycle handling (missed word
problem). I agree it's a low probability. But we've seen it, just a week
or two ago on a brand new box.
But
Ron,
This may be of interest...
http://citeseer.nj.nec.com/stone00when.html
When The CRC and TCP Checksum Disagree
Jonathan Stone, Craig Partridge SIGCOMM
-Sandeep
On Thu, 27 Sep 2001, Ronald G Minnich wrote:
I have a question on the checksum offloading. Has anyone measured any
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
At this level, you're basically screwed. A sofware checksum isn't
even an option on other PCI users, like disk controllers. If you
don't trust your PCI chipset, what do you do about things like that?
I'm rather curious -- what was the
Oh, yeah- I forgot about this. Jonathon is a pretty good NetBSD hacker..
On Thu, 27 Sep 2001, Sandeep Joshi wrote:
Ron,
This may be of interest...
http://citeseer.nj.nec.com/stone00when.html
When The CRC and TCP Checksum Disagree
Jonathan Stone, Craig Partridge SIGCOMM
Ronald G Minnich writes:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
At this level, you're basically screwed. A sofware checksum isn't
even an option on other PCI users, like disk controllers. If you
don't trust your PCI chipset, what do you do about things like that?
I'm
Louis A. Mamakos writes:
The other type of failure you might not catch are software errors; that
is, where a packet is produced by the network stack and then is
subsequently stomped on by a random store from some other code. Or
a mis-programmed I/O card with scatter/gather
Louis A. Mamakos writes:
I was referring to the case on the transmit side where the wrong
data get's gathered up by the DMA engine because of software related
errors. You get a valid checksum, but for the wrong data. You might
have the wrong data because a drive screwed up setting the
Louis A. Mamakos writes:
I was referring to the case on the transmit side where the wrong
data get's gathered up by the DMA engine because of software related
errors. You get a valid checksum, but for the wrong data. You might
have the wrong data because a drive screwed up
Louis A. Mamakos writes:
Folks ought to consider the likelyhood of this class of data
corruption, unlikely as it is, and weigh it along with the impact on
your application, and the differences in performance and loading.
Agreed. Very well said, by the way..
Drew
To Unsubscribe:
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
Geez. All I wanted to do was pat Jonathan on the back for coming up
with what is apparently the most flexible and well though out
mechanism out there.
it's great work. I was mainly curious to see if anyone had measured this
kind of problem.
Hi all,
Pardon the cross-posting. :-)
I'd like to look at closing down / making inactive the squid22 and
squid23 ports. The squid-2.2 and squid-2.3 codebases have been
inactive and largely unsupported by the squid developers (read: myself
inclusive here) for some time now, and I'd like to
To all our fans!!
Welsh Fantasy Football has paid your entrance fee to the
WELSH FANTASY FOOTBALL GAME 2001
Go to www.welshfantasyfootball.com
you have to be in it to WIN it!!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
:
:On Sunday, 23rd September 2001, Poul-Henning Kamp wrote:
:
:Things to look out for:
:
:1. !ufs filesystems
:
:I am irredeemably slack for not testing this a lot but...
:
:I believe I saw bad interactions between vmiodirenable and isofs on 4.3-R.
:
:I mounted a CD, looked at stuff on it, did a
I totally forgot about that one. Your fix looks good, I'll start testing
it.
The bigger picture here is that vinvalbuf() is not typically called
while a vnode is still active. NFS calls it on active vnodes in order
to invalidate the cache when the client detects that the
Yesterday, I used a script on my bridge that pretty much brought down
the entire network segment it was connected to. The script in question,
was found in /usr/share/examples/netgraph -- called 'ether.bridge'. I
modified the script, and ran it -- boom. Problems galore!
At the time, the bridge
well, maybe if you told us what you modified, and what happenned.
On Thu, 27 Sep 2001, Robert Hough wrote:
Yesterday, I used a script on my bridge that pretty much brought down
the entire network segment it was connected to. The script in question,
was found in
On Thu, Sep 27, 2001, Julian Elischer wrote:
well, maybe if you told us what you modified, and what happenned.
$ diff /usr/share/examples/netgraph/ether.bridge ~/eth_bridge.sh
41,42c41,42
BRIDGE_IFACES=ed0 fxp0 fxp1
LOCAL_IFACE=fxp0
---
BRIDGE_IFACES=vx0 vx1
LOCAL_IFACE=
As far as
BRIDGE/DUMMYNET/net.link.ether.bridge=1/net.link.ether.bridge_ipfw=1
is one set of bridging code
ng_bridge is a completely separate (in my opinion, better, but I'm
biased) setr of code.
they might interract if you turn them both on at the same time
On Thu, 27 Sep 2001, Robert Hough wrote:
I had the stangest situation today where a new nic card was put into a
machine and then the machine did not start up. Placed the old nic card
back in the box and it still did not start up. Switched power supplies
with an exactly equal box and both machine booted up fine. This has
happened twice
On 28-Sep-2001 Dan wrote:
I had the stangest situation today where a new nic card was put into a
machine and then the machine did not start up. Placed the old nic card
back in the box and it still did not start up. Switched power supplies
with an exactly equal box and both machine
Dan wrote:
I had the stangest situation today where a new nic card was put into a
machine and then the machine did not start up. Placed the old nic card
back in the box and it still did not start up. Switched power supplies
with an exactly equal box and both machine booted up fine. This
ya but even putting the old nic back in the machine does not still boot
up. I don't think this has to do with the nic but you never know.
fxp1: Intel Pro 10/100B/100+ Ethernet
On Thu, 27 Sep 2001, Kent Stewart wrote:
Date: Thu, 27 Sep 2001 19:38:55 -0700
From: Kent Stewart [EMAIL
On Thu, Sep 27, 2001 at 08:04:40PM -0700, Dan wrote:
ya but even putting the old nic back in the machine does not still boot
up. I don't think this has to do with the nic but you never know.
fxp1: Intel Pro 10/100B/100+ Ethernet
You overloaded and burned out the power supply?
Kris
no, it worked when i put it in a different machine that was exactly the
same.
On Thu, 27 Sep 2001, Kris Kennaway wrote:
Date: Thu, 27 Sep 2001 19:59:05 -0700
From: Kris Kennaway [EMAIL PROTECTED]
To: Dan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: power
On Thu, 27 Sep 2001, Andrew Gallatin wrote:
Geez. All I wanted to do was pat Jonathan on the back for coming up
with what is apparently the most flexible and well though out
mechanism out there.
it's great work. I was mainly curious to see if anyone had measured this
kind of
In the last episode (Sep 27), Louis A. Mamakos said:
And I don't disagree with you, it's wonderful work.
What I guess I'm trying to get across is that like any tool, it ought to
be used properly and in an informed way. For instance, you can mount a
file system async or with soft updates,
Dan Nelson wrote:
Something to do would be to enable hardware checksumming on 1/2 your
machines, and compare the bad packet counts at reported by netstat on
the unchanged machines for (say) a 1-month period before and after the
change. That should tell you whether you're gaining or losing
Kent Stewart wrote:
There are problems with PSes when you use NICs with wake up
capability. The NIC may exceed the capability of one of your low
amperage voltages.
Kent
How much current can wake-on-LAN take? I wouldn't think it would be enough to
overload a power supply unless it
ehlo.
I'm creating a patch to kernel that requires to create a set
of files; names of files are generated inside kernel, i.e.,
strings belong to kernel address space.
Initially, I tried to use open(), but failed with EFAULT: open()
expects filename string is in userspace, and
Jim Bryant wrote:
Kent Stewart wrote:
There are problems with PSes when you use NICs with wake up
capability. The NIC may exceed the capability of one of your low
amperage voltages.
Kent
How much current can wake-on-LAN take? I wouldn't think it would be enough to
overload a
43 matches
Mail list logo
