Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-10 Thread FreeBSD

Graeme Dargie a écrit :


-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 06 February 2009 16:47

To: Graeme Dargie
Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

Graeme Dargie a écrit :

-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 04 February 2009 21:55

Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Graeme Dargie a écrit :

If you do a dmesg are you also showing a watchdog time out for the nic ?

I only ask as I am having the exact same problem with the exact same 
card and I have yet to find a solution, if I come across something I 
will let you know.


Regards
Graeme

Not a single time...sorry.


-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
18:58

To: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Hi everyone,

Just to put you in context, I applied the following patch to make the 
card available:


SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.

---

I don't have any issue related to that anymore. The problem is that I 
get link UP/DOWN a few times per hour on 3 identical machines that I 
dumped/restored. They are all pluged in a Cisco switch that works 
fine for every other PCs.


Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

I tried to switch cables, but I got the same result.

There is the pciconf -lv output:

r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
rev=0x02 hdr=0x00

vendor = 'Realtek Semiconductor'
device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
class  = network
subclass   = ethernet

There is the output of vmstat -i:

interrupt  total   rate
irq18: re0 ehci0++ 63766  0
irq19: atapci0277001  3
cpu0: timer156068748   1961
Total  156409515   1966

Could it be related to the fact that there is re0 and ehci0++ on the 
same IRQ?


Thank you for your help,

Martin
I just tried with a brand new Dell 2708 switch and the problem is 
still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
(+- a few seconds).


Thanks again,

Martin


Just to follow-up on my own problem...

I tried to disable some options of the card with :
ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag

but nothing as changed. I just tried to download a big file (FreeBSD 
7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
transfer. The DVD downloaded successfully and I verified that the MD5 
are OK. BUT, /var/log/messages continue to tell me that:

Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN

during the transfer (which worked OK). I don't know if that can help 
someone to help me ;)


Thanks,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

I have a solution to this well a work around.

Add -tso to the relevant line in /etc/rc.conf

ifconfig_re0=inet 192.168.1.103  netmask 255.255.255.0 -tso

Adding -tso stops the link up / link down problem. Now I am understand that 
this may increase cpu if the traffic on the nic is high. I am sure some one the 
list will know of any other implications this may have.

It is a known problem and I site I read the bug had been submitted so hopefully it wont exist in 8.0 


Regards

Graeme



As I stated in my last post, I tried to disable a few options, including 
TSO. Still, I gived a try to your workaround. I now have this line in 
rc.conf:

ifconfig_re0=DHCP -tso

but I have the same problem (it disconnect every 10 minutes and ask for 
an IP to the DHCP).


Thanks for your suggestion,

Martin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org




I don't use DHCP so it never causes me a problem, have you considered setting a 
static IP address ?

Regards

Graeme



IT WORKS!!! As soon as I setted a static IP there is no deconnection 
anymore. Thanks

RE: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-10 Thread Graeme Dargie


-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 10 February 2009 17:22
To: Graeme Dargie
Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

Graeme Dargie a écrit :
 
 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] 
 Sent: 06 February 2009 16:47
 To: Graeme Dargie
 Cc: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1
 
 Graeme Dargie a écrit :
 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] 
 Sent: 04 February 2009 21:55
 Cc: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

 FreeBSD a écrit :
 Graeme Dargie a écrit :
 If you do a dmesg are you also showing a watchdog time out for the nic ?

 I only ask as I am having the exact same problem with the exact same 
 card and I have yet to find a solution, if I come across something I 
 will let you know.

 Regards
 Graeme
 Not a single time...sorry.

 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
 18:58
 To: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

 FreeBSD a écrit :
 Hi everyone,

 Just to put you in context, I applied the following patch to make the 
 card available:

 SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

 Since we don't request reset for rlphy(4), the link state 'UP'
 event from mii(4) may not be delivered if valid link was already
 established. To address the issue, check current link state after
 driving MII_TICK. This should fix a regression introduced in
 r185753 on fast ethernet controllers.

 ---

 I don't have any issue related to that anymore. The problem is that I 
 get link UP/DOWN a few times per hour on 3 identical machines that I 
 dumped/restored. They are all pluged in a Cisco switch that works 
 fine for every other PCs.

 Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
 Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

 I tried to switch cables, but I got the same result.

 There is the pciconf -lv output:

 r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
 rev=0x02 hdr=0x00
 vendor = 'Realtek Semiconductor'
 device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 class  = network
 subclass   = ethernet

 There is the output of vmstat -i:

 interrupt  total   rate
 irq18: re0 ehci0++ 63766  0
 irq19: atapci0277001  3
 cpu0: timer156068748   1961
 Total  156409515   1966

 Could it be related to the fact that there is re0 and ehci0++ on the 
 same IRQ?

 Thank you for your help,

 Martin
 I just tried with a brand new Dell 2708 switch and the problem is 
 still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
 (+- a few seconds).

 Thanks again,

 Martin

 Just to follow-up on my own problem...

 I tried to disable some options of the card with :
 ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag

 but nothing as changed. I just tried to download a big file (FreeBSD 
 7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
 transfer. The DVD downloaded successfully and I verified that the MD5 
 are OK. BUT, /var/log/messages continue to tell me that:
 Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
 Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
 Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
 Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN

 during the transfer (which worked OK). I don't know if that can help 
 someone to help me ;)

 Thanks,

 Martin

 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

 I have a solution to this well a work around.

 Add -tso to the relevant line in /etc/rc.conf

 ifconfig_re0=inet 192.168.1.103  netmask 255.255.255.0 -tso

 Adding -tso stops the link up / link down problem. Now I am understand that 
 this may increase cpu if the traffic on the nic is high. I am sure some one 
 the list will know of any other implications this may have.

 It is a known problem and I site I read the bug had been submitted so 
 hopefully it wont exist in 8.0 

 Regards

 Graeme

 
 As I stated in my last post, I tried to disable a few options, including 
 TSO. Still, I gived a try to your workaround. I now have this line in 
 rc.conf:
 ifconfig_re0=DHCP -tso
 
 but I have the same problem (it disconnect every 10 minutes and ask for 
 an IP to the DHCP).
 
 Thanks for your suggestion,
 
 Martin
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo

Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-06 Thread FreeBSD

Graeme Dargie a écrit :

-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 04 February 2009 21:55

Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Graeme Dargie a écrit :

If you do a dmesg are you also showing a watchdog time out for the nic ?

I only ask as I am having the exact same problem with the exact same 
card and I have yet to find a solution, if I come across something I 
will let you know.


Regards
Graeme

Not a single time...sorry.


-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
18:58

To: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Hi everyone,

Just to put you in context, I applied the following patch to make the 
card available:


SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.

---

I don't have any issue related to that anymore. The problem is that I 
get link UP/DOWN a few times per hour on 3 identical machines that I 
dumped/restored. They are all pluged in a Cisco switch that works 
fine for every other PCs.


Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

I tried to switch cables, but I got the same result.

There is the pciconf -lv output:

r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
rev=0x02 hdr=0x00

vendor = 'Realtek Semiconductor'
device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
class  = network
subclass   = ethernet

There is the output of vmstat -i:

interrupt  total   rate
irq18: re0 ehci0++ 63766  0
irq19: atapci0277001  3
cpu0: timer156068748   1961
Total  156409515   1966

Could it be related to the fact that there is re0 and ehci0++ on the 
same IRQ?


Thank you for your help,

Martin
I just tried with a brand new Dell 2708 switch and the problem is 
still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
(+- a few seconds).


Thanks again,

Martin



Just to follow-up on my own problem...

I tried to disable some options of the card with :
ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag

but nothing as changed. I just tried to download a big file (FreeBSD 
7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
transfer. The DVD downloaded successfully and I verified that the MD5 
are OK. BUT, /var/log/messages continue to tell me that:

Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN

during the transfer (which worked OK). I don't know if that can help 
someone to help me ;)


Thanks,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

I have a solution to this well a work around.

Add -tso to the relevant line in /etc/rc.conf

ifconfig_re0=inet 192.168.1.103  netmask 255.255.255.0 -tso

Adding -tso stops the link up / link down problem. Now I am understand that 
this may increase cpu if the traffic on the nic is high. I am sure some one the 
list will know of any other implications this may have.

It is a known problem and I site I read the bug had been submitted so hopefully it wont exist in 8.0 


Regards

Graeme



As I stated in my last post, I tried to disable a few options, including 
TSO. Still, I gived a try to your workaround. I now have this line in 
rc.conf:

ifconfig_re0=DHCP -tso

but I have the same problem (it disconnect every 10 minutes and ask for 
an IP to the DHCP).


Thanks for your suggestion,

Martin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


RE: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-06 Thread Graeme Dargie


-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 06 February 2009 16:47
To: Graeme Dargie
Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

Graeme Dargie a écrit :
 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] 
 Sent: 04 February 2009 21:55
 Cc: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1
 
 FreeBSD a écrit :
 Graeme Dargie a écrit :
 If you do a dmesg are you also showing a watchdog time out for the nic ?

 I only ask as I am having the exact same problem with the exact same 
 card and I have yet to find a solution, if I come across something I 
 will let you know.

 Regards
 Graeme
 Not a single time...sorry.

 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
 18:58
 To: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

 FreeBSD a écrit :
 Hi everyone,

 Just to put you in context, I applied the following patch to make the 
 card available:

 SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

 Since we don't request reset for rlphy(4), the link state 'UP'
 event from mii(4) may not be delivered if valid link was already
 established. To address the issue, check current link state after
 driving MII_TICK. This should fix a regression introduced in
 r185753 on fast ethernet controllers.

 ---

 I don't have any issue related to that anymore. The problem is that I 
 get link UP/DOWN a few times per hour on 3 identical machines that I 
 dumped/restored. They are all pluged in a Cisco switch that works 
 fine for every other PCs.

 Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
 Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

 I tried to switch cables, but I got the same result.

 There is the pciconf -lv output:

 r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
 rev=0x02 hdr=0x00
 vendor = 'Realtek Semiconductor'
 device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 class  = network
 subclass   = ethernet

 There is the output of vmstat -i:

 interrupt  total   rate
 irq18: re0 ehci0++ 63766  0
 irq19: atapci0277001  3
 cpu0: timer156068748   1961
 Total  156409515   1966

 Could it be related to the fact that there is re0 and ehci0++ on the 
 same IRQ?

 Thank you for your help,

 Martin
 I just tried with a brand new Dell 2708 switch and the problem is 
 still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
 (+- a few seconds).

 Thanks again,

 Martin

 
 Just to follow-up on my own problem...
 
 I tried to disable some options of the card with :
 ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag
 
 but nothing as changed. I just tried to download a big file (FreeBSD 
 7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
 transfer. The DVD downloaded successfully and I verified that the MD5 
 are OK. BUT, /var/log/messages continue to tell me that:
 Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
 Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
 Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
 Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN
 
 during the transfer (which worked OK). I don't know if that can help 
 someone to help me ;)
 
 Thanks,
 
 Martin
 
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
 
 I have a solution to this well a work around.
 
 Add -tso to the relevant line in /etc/rc.conf
 
 ifconfig_re0=inet 192.168.1.103  netmask 255.255.255.0 -tso
 
 Adding -tso stops the link up / link down problem. Now I am understand that 
 this may increase cpu if the traffic on the nic is high. I am sure some one 
 the list will know of any other implications this may have.
 
 It is a known problem and I site I read the bug had been submitted so 
 hopefully it wont exist in 8.0 
 
 Regards
 
 Graeme
 

As I stated in my last post, I tried to disable a few options, including 
TSO. Still, I gived a try to your workaround. I now have this line in 
rc.conf:
ifconfig_re0=DHCP -tso

but I have the same problem (it disconnect every 10 minutes and ask for 
an IP to the DHCP).

Thanks for your suggestion,

Martin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org




I don't use DHCP so it never causes me a problem, have you considered setting a 
static IP address ?

Regards

Graeme

RE: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-05 Thread Graeme Dargie
-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 04 February 2009 21:55
Cc: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :
 Graeme Dargie a écrit :
 If you do a dmesg are you also showing a watchdog time out for the nic ?

 I only ask as I am having the exact same problem with the exact same 
 card and I have yet to find a solution, if I come across something I 
 will let you know.

 Regards
 Graeme
 
 Not a single time...sorry.
 

 -Original Message-
 From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
 18:58
 To: freebsd-questions@freebsd.org
 Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

 FreeBSD a écrit :
 Hi everyone,

 Just to put you in context, I applied the following patch to make the 
 card available:

 SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

 Since we don't request reset for rlphy(4), the link state 'UP'
 event from mii(4) may not be delivered if valid link was already
 established. To address the issue, check current link state after
 driving MII_TICK. This should fix a regression introduced in
 r185753 on fast ethernet controllers.

 ---

 I don't have any issue related to that anymore. The problem is that I 
 get link UP/DOWN a few times per hour on 3 identical machines that I 
 dumped/restored. They are all pluged in a Cisco switch that works 
 fine for every other PCs.

 Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
 Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

 I tried to switch cables, but I got the same result.

 There is the pciconf -lv output:

 r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
 rev=0x02 hdr=0x00
 vendor = 'Realtek Semiconductor'
 device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 class  = network
 subclass   = ethernet

 There is the output of vmstat -i:

 interrupt  total   rate
 irq18: re0 ehci0++ 63766  0
 irq19: atapci0277001  3
 cpu0: timer156068748   1961
 Total  156409515   1966

 Could it be related to the fact that there is re0 and ehci0++ on the 
 same IRQ?

 Thank you for your help,

 Martin

 I just tried with a brand new Dell 2708 switch and the problem is 
 still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
 (+- a few seconds).

 Thanks again,

 Martin


Just to follow-up on my own problem...

I tried to disable some options of the card with :
ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag

but nothing as changed. I just tried to download a big file (FreeBSD 
7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
transfer. The DVD downloaded successfully and I verified that the MD5 
are OK. BUT, /var/log/messages continue to tell me that:
Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN

during the transfer (which worked OK). I don't know if that can help 
someone to help me ;)

Thanks,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

I have a solution to this well a work around.

Add -tso to the relevant line in /etc/rc.conf

ifconfig_re0=inet 192.168.1.103  netmask 255.255.255.0 -tso

Adding -tso stops the link up / link down problem. Now I am understand that 
this may increase cpu if the traffic on the nic is high. I am sure some one the 
list will know of any other implications this may have.

It is a known problem and I site I read the bug had been submitted so hopefully 
it wont exist in 8.0 

Regards

Graeme

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-02-04 Thread FreeBSD

FreeBSD a écrit :

Graeme Dargie a écrit :

If you do a dmesg are you also showing a watchdog time out for the nic ?

I only ask as I am having the exact same problem with the exact same 
card and I have yet to find a solution, if I come across something I 
will let you know.


Regards
Graeme


Not a single time...sorry.



-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] Sent: 26 January 2009 
18:58

To: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Hi everyone,

Just to put you in context, I applied the following patch to make the 
card available:


SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.

---

I don't have any issue related to that anymore. The problem is that I 
get link UP/DOWN a few times per hour on 3 identical machines that I 
dumped/restored. They are all pluged in a Cisco switch that works 
fine for every other PCs.


Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

I tried to switch cables, but I got the same result.

There is the pciconf -lv output:

r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec 
rev=0x02 hdr=0x00

vendor = 'Realtek Semiconductor'
device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
class  = network
subclass   = ethernet

There is the output of vmstat -i:

interrupt  total   rate
irq18: re0 ehci0++ 63766  0
irq19: atapci0277001  3
cpu0: timer156068748   1961
Total  156409515   1966

Could it be related to the fact that there is re0 and ehci0++ on the 
same IRQ?


Thank you for your help,

Martin


I just tried with a brand new Dell 2708 switch and the problem is 
still there. I just confirmed that the UP/DOWN occurs every 10 minutes 
(+- a few seconds).


Thanks again,

Martin



Just to follow-up on my own problem...

I tried to disable some options of the card with :
ifconfig re0 -rxcsum -txcsum -tso -lro -vlanhwtag

but nothing as changed. I just tried to download a big file (FreeBSD 
7.1-REL DVD iso in fact) to see if the deconnection occurs even during a 
transfer. The DVD downloaded successfully and I verified that the MD5 
are OK. BUT, /var/log/messages continue to tell me that:

Feb  4 16:09:29 term003 kernel: re0: link state changed to UP
Feb  4 16:19:26 term003 kernel: re0: link state changed to DOWN
Feb  4 16:19:30 term003 kernel: re0: link state changed to UP
Feb  4 16:19:32 term003 kernel: re0: link state changed to DOWN

during the transfer (which worked OK). I don't know if that can help 
someone to help me ;)


Thanks,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-01-26 Thread FreeBSD

FreeBSD a écrit :

Hi everyone,

Just to put you in context, I applied the following patch to make the 
card available:


SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.

---

I don't have any issue related to that anymore. The problem is that I 
get link UP/DOWN a few times per hour on 3 identical machines that I 
dumped/restored. They are all pluged in a Cisco switch that works fine 
for every other PCs.


Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

I tried to switch cables, but I got the same result.

There is the pciconf -lv output:

r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 
hdr=0x00

vendor = 'Realtek Semiconductor'
device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
class  = network
subclass   = ethernet

There is the output of vmstat -i:

interrupt  total   rate
irq18: re0 ehci0++ 63766  0
irq19: atapci0277001  3
cpu0: timer156068748   1961
Total  156409515   1966

Could it be related to the fact that there is re0 and ehci0++ on the 
same IRQ?


Thank you for your help,

Martin


I just tried with a brand new Dell 2708 switch and the problem is still 
there. I just confirmed that the UP/DOWN occurs every 10 minutes (+- a 
few seconds).


Thanks again,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


RE: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-01-26 Thread Graeme Dargie
If you do a dmesg are you also showing a watchdog time out for the nic ?

I only ask as I am having the exact same problem with the exact same card and I 
have yet to find a solution, if I come across something I will let you know.

Regards
Graeme

-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 26 January 2009 18:58
To: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :
 Hi everyone,
 
 Just to put you in context, I applied the following patch to make the 
 card available:
 
 SVN rev 186389 on 2008-12-22 00:46:22Z by yongari
 
 Since we don't request reset for rlphy(4), the link state 'UP'
 event from mii(4) may not be delivered if valid link was already
 established. To address the issue, check current link state after
 driving MII_TICK. This should fix a regression introduced in
 r185753 on fast ethernet controllers.
 
 ---
 
 I don't have any issue related to that anymore. The problem is that I 
 get link UP/DOWN a few times per hour on 3 identical machines that I 
 dumped/restored. They are all pluged in a Cisco switch that works fine 
 for every other PCs.
 
 Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
 Jan 26 06:09:17 term005 kernel: re0: link state changed to UP
 
 I tried to switch cables, but I got the same result.
 
 There is the pciconf -lv output:
 
 r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 
 hdr=0x00
 vendor = 'Realtek Semiconductor'
 device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 class  = network
 subclass   = ethernet
 
 There is the output of vmstat -i:
 
 interrupt  total   rate
 irq18: re0 ehci0++ 63766  0
 irq19: atapci0277001  3
 cpu0: timer156068748   1961
 Total  156409515   1966
 
 Could it be related to the fact that there is re0 and ehci0++ on the 
 same IRQ?
 
 Thank you for your help,
 
 Martin

I just tried with a brand new Dell 2708 switch and the problem is still 
there. I just confirmed that the UP/DOWN occurs every 10 minutes (+- a 
few seconds).

Thanks again,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

2009-01-26 Thread FreeBSD

Graeme Dargie a écrit :

If you do a dmesg are you also showing a watchdog time out for the nic ?

I only ask as I am having the exact same problem with the exact same card and I 
have yet to find a solution, if I come across something I will let you know.

Regards
Graeme


Not a single time...sorry.



-Original Message-
From: FreeBSD [mailto:free...@optiksecurite.com] 
Sent: 26 January 2009 18:58

To: freebsd-questions@freebsd.org
Subject: Re: Link UP/DOWN problem with re0 on FreeBSD 7.1

FreeBSD a écrit :

Hi everyone,

Just to put you in context, I applied the following patch to make the 
card available:


SVN rev 186389 on 2008-12-22 00:46:22Z by yongari

Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.

---

I don't have any issue related to that anymore. The problem is that I 
get link UP/DOWN a few times per hour on 3 identical machines that I 
dumped/restored. They are all pluged in a Cisco switch that works fine 
for every other PCs.


Jan 26 06:09:15 term005 kernel: re0: link state changed to DOWN
Jan 26 06:09:17 term005 kernel: re0: link state changed to UP

I tried to switch cables, but I got the same result.

There is the pciconf -lv output:

r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 
hdr=0x00

vendor = 'Realtek Semiconductor'
device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
class  = network
subclass   = ethernet

There is the output of vmstat -i:

interrupt  total   rate
irq18: re0 ehci0++ 63766  0
irq19: atapci0277001  3
cpu0: timer156068748   1961
Total  156409515   1966

Could it be related to the fact that there is re0 and ehci0++ on the 
same IRQ?


Thank you for your help,

Martin


I just tried with a brand new Dell 2708 switch and the problem is still 
there. I just confirmed that the UP/DOWN occurs every 10 minutes (+- a 
few seconds).


Thanks again,

Martin

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org