Ok, there's packet loss. From this extract you can see
that the client receives through sequence 641, then the
next packet it receives starts at sequence 993.
15:28:09.879928 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 609:641(32)
ack 64 win 33304 (DF) [tos 0x10]
15:28
Well Joe, I will try to give you some pointers as I have VMware(2.0.3)
working fine on 4.3 stable, running W2K.
Here is my setup
- local private LAN i.e. 192.168.0.*
- FreeBSD box has an ethernet address set to 192.168.0.254
- Other boxes/vmware hosts have addresses 192.168.0.5...n
- All bo
FreeBSD 4.4-RELEASE. Vmware is running correctly, and I have successfully
loaded windows98 into a virtual machine with no problems.
When I loaded vmware from the port, it asked me what kind of networking I
wanted, and I chose 'bridging'. I think.
Anyway, in my windows98 VM configuration, I see
It seems Nils Holland wrote:
> On Sat, Dec 29, 2001 at 10:42:20PM +0100, Søren Schmidt stood up and spoke:
> > It seems Matthew Dillon wrote:
> > > :Anyways could I have you guys read out all 256 PCI regs from the
> > > :main chip that is the 0x03051106 one ?
> > > :
> > > :-Søren
> > >
> > >
Saturday, December 29, 2001, 6:41:33 PM, you wrote:
JK> On Fri, Dec 28, 2001 at 07:27:36PM +0100, Tomas Svensson wrote:
>> ## several packets are lost here due to congestion, thanks to
>> TCP_NODELAY:
JK> No. These packets aren't lost to congestion. I can reproduce this
JK> pattern every time
On Sat, Dec 29, 2001 at 10:42:20PM +0100, Søren Schmidt stood up and spoke:
> It seems Matthew Dillon wrote:
> > :Anyways could I have you guys read out all 256 PCI regs from the
> > :main chip that is the 0x03051106 one ?
> > :
> > :-Søren
> >
> > How is this done?
>
> With pciconf, fx:
> I probably just looked in the wrong place. Array rebuild cannot be done
> in FreeBSD yet? Or am I wrong about this again? It would be nice to have
> this info added to ata(4) I think. Didn't find anything about RAID
> there. If a disk fails, is a message logged? Is there any way to view
> the st
> Whether the packet loss is random or not, there is packet loss occuring.
> What's the exact network setup between the two machines? Perhaps it's a
> collision occuring each time.
Please don't imply that normal half duplex Ethernet collisions cause
packet loss. They don't.
Steinar Haug, Nethel
Title: [±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ» 100% Â÷´ÜÇÏ´Â ¹æ¹ý !!
[±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ» 100% Â÷´ÜÇϴ¹ý
!!
ÄÄÀ» ¾Ë°í³ª¸é ½ºÆÔ¸ÞÀÏ °ÆÁ¤¾ÈÇÏ°í ¾ó¸¶µçÁö ¸ÞÀÏÀ» ÀÌ¿ëÇÒ ¼ö°¡ ÀÖÁö¿©~
À¥¸ÞÀÏ ¸Þ´ºÁß È¯°æ¼³Á¤À̳ª¿É¼Ç¼±ÅÃ
Title: [±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ» 100% Â÷´ÜÇÏ´Â ¹æ¹ý !!
[±¤°í]¹®±¸°¡ µé¾î°£ ¸ÞÀÏÀ» 100% Â÷´ÜÇϴ¹ý
!!
ÄÄÀ» ¾Ë°í³ª¸é ½ºÆÔ¸ÞÀÏ °ÆÁ¤¾ÈÇÏ°í ¾ó¸¶µçÁö ¸ÞÀÏÀ» ÀÌ¿ëÇÒ ¼ö°¡ ÀÖÁö¿©~
À¥¸ÞÀÏ ¸Þ´ºÁß È¯°æ¼³Á¤À̳ª¿É¼Ç¼±ÅÃ
It seems Matthew Dillon wrote:
> :Anyways could I have you guys read out all 256 PCI regs from the
> :main chip that is the 0x03051106 one ?
> :
> :-Søren
>
> How is this done?
With pciconf, fx:
sos# pciconf -r -b pci0:0:0 0x0:0xff
06 11 05 03 06 00 10 22 03 00 00 06 00 08 00 00
08 00 0
:Anyways could I have you guys read out all 256 PCI regs from the
:main chip that is the 0x03051106 one ?
:
:-Søren
How is this done?
-Matt
Matthew Dillon
<[EMAIL PROTEC
On Sat, Dec 29, 2001 at 01:59:28PM -0500, Mike Silbersack wrote:
>
> I'm going to blame the USB ethernet driver for dropping packets; Thomas
> Zenker has been reporting similar problems on -net. He says that he did
> not have problems with packet loss with 4.3, but has not been able to
> track d
On Sat, 29 Dec 2001, Josef Karthauser wrote:
> genius(laptop)/aue0 usb ethernet. (-current)
> |
> 10 base half duplex hub
> |
> 10 base half duplex hub
> |
> transwarp(dual processor server)/fxp0 onboard ethernet. (-stable).
I'm going to blame the USB ethernet driver for dropping packets; Thoma
On Sat, Dec 29, 2001 at 12:49:02PM -0500, Mike Silbersack wrote:
>
> > You are right that switching TCP_NODELAY off does fix it, but it's not
> > caused by congestion I can assure you.
>
>
> Whether the packet loss is random or not, there is packet loss occuring.
> What's the exact network setup
On Sat, 29 Dec 2001, Josef Karthauser wrote:
> On Fri, Dec 28, 2001 at 07:27:36PM +0100, Tomas Svensson wrote:
> > This just verifies what I said weeks ago.
> >
> > On the client side:
> >
> > ## several packets are lost here due to congestion, thanks to
> > TCP_NODELAY:
>
> No. These packets a
On Fri, Dec 28, 2001 at 07:27:36PM +0100, Tomas Svensson wrote:
> This just verifies what I said weeks ago.
>
> On the client side:
>
> ## several packets are lost here due to congestion, thanks to
> TCP_NODELAY:
No. These packets aren't lost to congestion. I can reproduce this
pattern every
S?ren Schmidt([EMAIL PROTECTED])@2001.12.29 16:43:22 +:
> It seems Alson van der Meulen wrote:
> > What this driver does have, and we don't, is support for RAID. AFAIK,
> > our own driver can only use it as an ATA controller. There's no
>
> bzzst! *WRONG* we have had support for the RAID's on
top stopped working for non root
(it worked for non root on FBSD 4.3 install)
there is nothing in README or UPDATING about any change.
top
kvm_open: /dev/kmem: Permission denied
on FBSD 4.3:
ls -l /dev/kmem
crw-r- 1 root kmem2, 1 Apr 21 2001 /dev/kmem
ls -l /usr/bin/top
-r-xr-sr-x
It seems Alson van der Meulen wrote:
> S?ren Schmidt([EMAIL PROTECTED])@2001.12.29 10:15:03 +:
> > It seems S?ren Schmidt wrote:
> > > We already have support for the Fasttraks in the kernel (and have had that
> > > for a long time now), with code that is developed outside Promise.
> > > Howe
Hello!
I administer several FreeBSD systems, and noticed some
strange things with FDESC fs:
* First box:
FreeBSD 4.3-RC #0: Sun Apr 22 07:14:16 2001
# mount
/dev/ad0a on / (ufs, local, noatime, soft-updates)
procfs on /proc (procfs, local)
kernfs on /ker
S?ren Schmidt([EMAIL PROTECTED])@2001.12.29 10:15:03 +:
> It seems S?ren Schmidt wrote:
> > We already have support for the Fasttraks in the kernel (and have had that
> > for a long time now), with code that is developed outside Promise.
> > However it still needs a bit of work, but with a li
On Sat, Dec 29, 2001 at 04:45:33PM +0530, Anjali Kulkarni wrote:
> Hi,
>
> Can any one tell me how to increase the default kernel memory limit? ie., the memory
>from which mallocs occur(from kmem_map). I tried making the VM_KMEM_SIZE option to
>the maximum(200M), but it didnt seem to have any e
Hello!
I know about sysctl "kern.ps_showallprocs", but it is not
very convenient because in this case only root will be able
to see all processes, and I want to wheel group to see them
all as well. I modified kern_proc.c a bit, could you please
comment on it, and say will it work or not, and how
Hi,
Can any one tell me how to increase the default
kernel memory limit? ie., the memory from which mallocs occur(from kmem_map). I
tried making the VM_KMEM_SIZE option to the maximum(200M), but it didnt seem to
have any effect:(. M/c memory is 1GB.
Thanks,
Anjali
It seems Søren Schmidt wrote:
> We already have support for the Fasttraks in the kernel (and have had that
> for a long time now), with code that is developed outside Promise.
> However it still needs a bit of work, but with a little luck that should
> clear up soon..
BTW, it is interesting to
It seems Alson van der Meulen wrote:
> When searching for FreeBSD support for the Promise 20265r (FastTrack
> RAID, ATA100, integrated on some mainboards), I came across this, it
> looks like a FreeBSD RAID driver for this controller. It doesn't seem to
> be an official released driver, this is th
27 matches
Mail list logo
