On Thu, 8 Jan 2004, Adam McLaurin wrote:
> First, both speed & duplex are set manualyl at both ends. In fact, I did
> this more than a year ago as a recommendation to solve this particular
> problem we're discussing now. In other words, the problem existed before
> I manually set speed/duplex, an
On Thu, 08 Jan 2004 13:02:23 +1000
Q <[EMAIL PROTECTED]> wrote:
> The first thing you should try is setting the ethernet card to use
> autosense. This enables the autosense pulse to be sent to the switch,
> without this some passive/unmanaged switches can get very confused and
> switch speeds and
On Thu, Jan 08, 2004 at 10:14:36AM -0800, Steve Francis wrote:
> Look at the dumbtimer mount option in mount_nfs
Hi Steve,
Sorry. I should have mentioned that they are already mounted with that option:
192.168.1.1:/vol/vol1/claramail /clara nfs rw,dumbtimer 0 0
in the UDP case and
192
Good evening,
I am seeking some advice on some errors I am seeing in the logs of the machines
in a mail cluster I am responsible for. The errors do not seem to be causing
any operational impact, but equally, I'm inclined to investigate the source of
the warnings in any case.
The log messages in q
> Richard Wendland wrote:
> Haven't read all of that yet.
>> It's important to remember that if fragmentation takes place, and a
>> fragment is lost, the other fragment(s) will wait for quite some time
>> in a re-assembly buffer (maybe up to 63 seconds). While they are
>> waiting they are at qui
Richard Wendland wrote:
> > 5. Random ip_id is already a kernel option but it is *not* enabled by
> >default in 5.2RC2 GENERIC or -current.
>
> I don't think random ip_id should be enabled by default. The reduction
> in ip_id cycle from 64k is a real re-assembly risk on modern high-speed
> ne
Richard Wendland wrote:
>
> > I've attached a patch that fixes the problem with FIN/ACK and one more
> > case which got it wrong.
>
> Well done! I couldn't track that down.
>
> > 1. Do you think it is necessary to do a htons() on the randomized
> > ip_id too? I'd say yes if there is a cas
I was testing one of Warner's patches on my laptop and found that it
paniced during boot. The trigger was that fxp0 couldn't gets its irq
configured in fxp_attach(), so it called ether_ifdetach(), which
eventually ended up calling in6_ifdetach(), which blew up at the line of
code marked below:
