[Bug 189088] Assigning same IP to multiple interfaces in different FIBs only creates a host route for the first

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189088

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable12?,
   ||mfc-stable11?
   Keywords||needs-patch, needs-qa
Summary|Assigning the same IP to|Assigning same IP to
   |multiple interfaces in  |multiple interfaces in
   |different FIBs creates a|different FIBs only creates
   |host route for only one.|a host route for the first
   Priority|Normal  |---
   Severity|Affects Only Me |Affects Some People

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #78 from László Károlyi  ---
(In reply to Eugene Grosbein from comment #76)
Alright, it seems I managed to start my server with the newly compiled driver:

re0:  port 0xd000-0xd0ff mem
0xf7204000-0xf7204fff,0xf720-0xf7203fff irq 35 at device 0.0 on pci8
re0: Using Memory Mapping!
re0: Using 1 MSI-X message
re0: ASPM disabled
re0: version:1.96.04

There were no "module_register" errors in the dmesg, but looking at the output,
this is the new driver.

I'll try to do some load tests in the upcoming days and see what gives.

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IF_DRV_PREPEND unlocked?

[John-Mark Gurney]

Marko Zec wrote this message on Fri, Jul 17, 2020 at 23:54 +0200:
> On Fri, 17 Jul 2020 11:56:09 -0700
> John-Mark Gurney  wrote:
> > Marko Zec wrote this message on Fri, Jul 17, 2020 at 12:03 +0200:
> ...
> > > #define IFQ_DRV_IS_EMPTY(ifq) \
> > > (((ifq)->ifq_drv_len == 0) && ((ifq)->ifq_len == 0))
> > > 
> > > So, if per altq(9) the contract is that with IFQ_DRV_* the ifq_drv_*
> > > fields should be protected by some caller-provided mechanism, while
> > > the other ifq_* fields will be implictly protected by ifq_mtx, how
> > > can accessing ifw_len without holding ifq_mtx in the above example
> > > be safe?  
> > 
> > Reading is safe when you aren't modifying it, and only using it to
> > inform if you should recheck w/ a lock...
> > 
> > This way a driver can do:
> > if (!IFQ_DRV_IS_EMPTY(>if_snd)) {
> > mtx_lock(sc->sc_mtx);
> > for (;;) {
> > IFQ_DRV_DEQUEUE(>if_snd, m);
> > if (m == NULL)
> > break;
> > sendpkt(m);
> > }
> > mtx_unlock(sc->sc_mtx);
> > }
> > 
> > which saves an expensive lock/unlock op when there are no packets
> > in the queue...
> 
> The above snippet is fine even if IFQ_DRV_IS_EMPTY() returns 0 during a
> race with another thread: per altq(9) the subsequent (then properly
> locked) IFQ_DRV_DEQUEUE() might find out that the queue is actually
> empty, and bail out if (m == NULL).
> 
> But what if IFQ_DRV_IS_EMPTY() returns 1 due to a race with another
> thread which has just executed IFQ_ENQUEUE() (invisible to the first
> thread due to lack of synchronization), and therefore leaves the mbuf in
> the queue, instead of dequeuing and processing it?

This is where the _OACTIVE flag comes into play..  IFQ_HANDOFF_ADJ
checks the flag, and calls if_start if it's not set..  (hmm, do we
need a barrier here to ensure that enqueue completes before we check
the _OACTIVE flag, as this check of the flag is unlocked?)  As long
the driver has not set the _OACTIVE flag, the if_start routine will
be called for the enqueued packet...

It's only a problem if the driver does an unlocked check for the queue
and the driver has set the _OACTIVE flag, AND the driver will not do
a future check of the queue, like it's suppose to when it finishes
a packet TX and clears the _OACTIVE flag...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How to increase the size of the MAC address caching table?

[Rodney W. Grimes]

> 18.07.2020 16:16, Alexander V. Chernikov ?:
> > 18.07.2020, 13:56, "Alexandr Baryshnyev" :
> > 
> > Hello everybody.
> > 
> >  ???I have about 1,500 devices on the network, but in fact the MAC 
> > address table on the central router running Freebsd
> > 12.0 never contains more than 1000 with small cached records. In the 
> > network, there are short-term random interruptions
> > between different hosts and the router. The connection to the Internet 
> > on different computers in the network is lost for
> > a short time. No apparent cause of these breaks was found.
> > 
> > How often does this happens and what is the average "short-term" duration?
> > I'd look into route -n monitor (don't remember if arp state reporting was 
> > merged into 12.0) and try to tcpdump arp 
> > traffic to get understanding what's happening here.
> > Also: does this router perform TCP termination of the flows toward Internet?
> 
> Breaks occur for no apparent reason. If you take one computer on the network, 
> it first works without problems for a long 
> time, then it suddenly starts breaks: one minute there is no connection, then 
> there are a few minutes and so on in a 
> circle. After a while (sometimes from one to three days) normal operation on 
> this computer resumes, but the problem goes 
> to another computer on the network and there is the same thing that happened 
> on the previous computer.

Since we are talking arp I am going to assume no routing protocol is active on 
this collision domain.
Please correct me if I am wrong about this.

What is the switching topology of this 1500 node collision domain?
Is it possible leaf switches are occasionally experiencing a MAC table overflow?
How are IP addresses assigned, if by DHCP what are the lease lengths?
Is it possible an IP is getting recycled while the node still thinks it has a 
valid lease?

> 
> >  ???There is a suspicion that the MAC address table on the FreeBSD 
> > router has a limited size, about 1000 with a small
> > record maximum. Is that so? Is it possible to increase the size of this 
> > table if it is limited? An internet search was
> > not successful.
> > 
> > It's not limited.
> 
> OK, thank you. So we have another cause for our problem.
> 
> >  ??Help me, please.
> > 
> >  ?> arp -an | grep -ve incomplete | wc -l

What are these incomplete entries you filtered out?
How many are there and why are the occuring?

> >  ?1055
> > 
> > "Incomplete" are still entries in the per-interface mac address table. 
> > What's the size with incomplete ones?
> 
>  > arp -an | wc -l
>  1183
>  > ifconfig bridge0 addr | wc -l
>  1214

You are using FreeBSD as a transparent bridge for 1214 nodes?

I know I only asked a lot of questions but hopefully some of the answers might 
provide an insight into what is going wrong.

>  ? Thank you.
> -- 
> Best regards,
> Alexandr B. Baryshnyev, e-mail: a...@abbon.net

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 189088] Assigning the same IP to multiple interfaces in different FIBs creates a host route for only one.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189088

Allan Jude  changed:

   What|Removed |Added

 CC||allanj...@freebsd.org

--- Comment #11 from Allan Jude  ---
Thanks for looking at this

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046

--- Comment #7 from dmilith  ---
(In reply to Kristof Provost from comment #6)
I confirm that patch fixes KP with my build. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How to increase the size of the MAC address caching table?

[Alexandr Baryshnyev]

18.07.2020 16:16, Alexander V. Chernikov пишет:

18.07.2020, 13:56, "Alexandr Baryshnyev" :

Hello everybody.

    I have about 1,500 devices on the network, but in fact the MAC address 
table on the central router running Freebsd
12.0 never contains more than 1000 with small cached records. In the 
network, there are short-term random interruptions
between different hosts and the router. The connection to the Internet on 
different computers in the network is lost for
a short time. No apparent cause of these breaks was found.

How often does this happens and what is the average "short-term" duration?
I'd look into route -n monitor (don't remember if arp state reporting was merged into 12.0) and try to tcpdump arp 
traffic to get understanding what's happening here.

Also: does this router perform TCP termination of the flows toward Internet?


Breaks occur for no apparent reason. If you take one computer on the network, it first works without problems for a long 
time, then it suddenly starts breaks: one minute there is no connection, then there are a few minutes and so on in a 
circle. After a while (sometimes from one to three days) normal operation on this computer resumes, but the problem goes 
to another computer on the network and there is the same thing that happened on the previous computer.



    There is a suspicion that the MAC address table on the FreeBSD router 
has a limited size, about 1000 with a small
record maximum. Is that so? Is it possible to increase the size of this 
table if it is limited? An internet search was
not successful.

It's not limited.


OK, thank you. So we have another cause for our problem.


   Help me, please.

  > arp -an | grep -ve incomplete | wc -l
  1055

"Incomplete" are still entries in the per-interface mac address table. What's 
the size with incomplete ones?


> arp -an | wc -l
1183
> ifconfig bridge0 addr | wc -l
1214

  Thank you.
--
   Best regards,
   Alexandr B. Baryshnyev, e-mail: a...@abbon.net
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How to increase the size of the MAC address caching table?

[Alexandr Baryshnyev]

18.07.2020 16:16, Alexander V. Chernikov пишет:

18.07.2020, 13:56, "Alexandr Baryshnyev" :

Hello everybody.

    I have about 1,500 devices on the network, but in fact the MAC address 
table on the central router running Freebsd
12.0 never contains more than 1000 with small cached records. In the 
network, there are short-term random interruptions
between different hosts and the router. The connection to the Internet on 
different computers in the network is lost for
a short time. No apparent cause of these breaks was found.

How often does this happens and what is the average "short-term" duration?
I'd look into route -n monitor (don't remember if arp state reporting was merged into 12.0) and try to tcpdump arp 
traffic to get understanding what's happening here.

Also: does this router perform TCP termination of the flows toward Internet?


    There is a suspicion that the MAC address table on the FreeBSD router 
has a limited size, about 1000 with a small
record maximum. Is that so? Is it possible to increase the size of this 
table if it is limited? An internet search was
not successful.

It's not limited.


   Help me, please.

  > arp -an | grep -ve incomplete | wc -l
  1055






"Incomplete" are still entries in the per-interface mac address table. What's 
the size with incomplete ones?



arp -an | wc -l

1183

ifconfig bridge0 addr | wc -l

1214




   Thank you.

--
 Best regards,
 Alexandr B. Baryshnyev, e-mail: a...@abbon.net 
___
freebsd-net@freebsd.org  mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org 
"



--
   Best regards,
   Alexandr B. Baryshnyev, e-mail: a...@abbon.net
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

net.add_addr_allfibs=1 behaviour deprecation

[Alexander V . Chernikov]

Dear FreeBSD users,

I would like to make net.add_addr_allfibs=0 as the default system behaviour and 
remove net.add_addr_allfibs.
To do so, I would like to collect use cases with net.add_addr_allfibs=1 and 
multiple fibs, to ensure they can still be supported after removal.

Background:

Multi-fib support was added in r17 [1], 12 years ago. Addition of interface 
addresses to all fibs was a feature from day 1.
The `net.add_addr_allfibs` sysctl  was added in r180840 [2], 12 years ago.

Problem:
The goal of the fib support is to provide multiple independent routing tables, 
isolated from each other.
`net.add_addr_allfibs` default tries to shift gears in the opposite direction, 
unconditionally inserting all addresses to all of the fibs.

It complicates the logic, kernel code and makes control plane performance 
decrease with the number of fibs.
It make impossible to use the same prefixes in multiple fibs, which may be 
desired given shortage of IPv4 address space.

I do understand that there are some cases where such behaviour is desired.
For example, it can be used to achieve VRF route leaking or binding on address 
from different fibs.
I would like to collect such cases to consider supporting them in a different 
way.


The goal is to make net.add_addr_allfibs=0 default behaviour and remove 
net.add_addr_allfibs.
It will simplify kernel fib-related code and allow bringing more fib-related 
features. It will also improve fib scaling.


Timeline:
Aug 1: summarising feedback and the usecases, decision on proceeding further
Aug 20 (tentative):  patches for supported usecases
Sep 15 (tentative):  net.add_addr_allfibs removal.

[1]: [base Contents of 
/head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17=markup)
[2]: [base Diff of 
/head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839=180840;)

/Alexander
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How to increase the size of the MAC address caching table?

[Alexander V . Chernikov]

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

How to increase the size of the MAC address caching table?

[Alexandr Baryshnyev]

Hello everybody.

  I have about 1,500 devices on the network, but in fact the MAC address table on the central router running Freebsd 
12.0 never contains more than 1000 with small cached records. In the network, there are short-term random interruptions 
between different hosts and the router. The connection to the Internet on different computers in the network is lost for 
a short time. No apparent cause of these breaks was found.


  There is a suspicion that the MAC address table on the FreeBSD router has a limited size, about 1000 with a small 
record maximum. Is that so? Is it possible to increase the size of this table if it is limited? An internet search was 
not successful.


 Help me, please.

> arp -an | grep -ve incomplete | wc -l
1055

 Thank you.

--
   Best regards,
   Alexandr B. Baryshnyev, e-mail: a...@abbon.net
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046

--- Comment #6 from Kristof Provost  ---
(In reply to Ryan Moeller from comment #4)
Thanks. I can reproduce that. It looks like the code to widen epoch didn't make
it into stable/12, so we need to enter epoch on bridge_input()/bridge_output()
ourselves.

See https://reviews.freebsd.org/D25715

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046

--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kp
Date: Sat Jul 18 12:43:11 UTC 2020
New revision: 363308
URL: https://svnweb.freebsd.org/changeset/base/363308

Log:
  bridge: Don't sleep during epoch

  While it doesn't trigger INVARIANTS or WITNESS on head it does in stable/12.
  There's also no reason for it, as we can easily report the out of memory
error
  to the caller (i.e. userspace). All of these can already fail.

  PR:   248046
  MFC after:3 days

Changes:
  head/sys/net/if_bridge.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #77 from László Károlyi  ---
(In reply to Eugene Grosbein from comment #76)
Thanks. I'll make some adjustments and will touch base later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #76 from Eugene Grosbein  ---
Sorry, it's releng/12.1 for 12.1-RELEASE-pX.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #75 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #71)

> Additional information, I used the stable/12 branch to check out for the 
> kernel sources:
> svn checkout https://svn.FreeBSD.org/base/stable/12 /usr/src/

This is the error. You have to use sources of same branch as of your GENERIC
kernel to build the module. If you use RELEASE-pX, then you mush checkout
releng/12 and not stable/12.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #74 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #70)

> but there's another, different error:
> https://i.imgur.com/TsSqp1g.png

You have mixup of incompatible kernel and module binaries.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #73 from László Károlyi  ---
(In reply to Eugene Grosbein from comment #72)
Hey Eugene,

that is what I did. See #71 and #70.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #72 from Eugene Grosbein  ---
(In reply to László Károlyi from comment #68)

> I get no overriding message in dmesg

Loader messages do not get to the dmesg buffer. Instead, use "kldstat -v" to
verify that module is loaded. And you cannot load the module after kernel
version is activated (registered), so use /boot/loader.conf or
/boot/nextboot.conf

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #71 from László Károlyi  ---
(In reply to Alex Dupre from comment #69)
Additional information, I used the stable/12 branch to check out for the kernel
sources:

svn checkout https://svn.FreeBSD.org/base/stable/12 /usr/src/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #70 from László Károlyi  ---
(In reply to Alex Dupre from comment #69)
I followed the instructions but the module still won't load.

I've fired up a virtual machine to test locally with the same
patchlevel/kernel/compiled module, and I get various error messages.

When loading it from the boot prompt, I get a "can't find kernel" error
message:
https://i.imgur.com/TtIAW8h.png

On automatically loading from loader.conf, I have to halt the virtualmachine to
be able to see the message but there's another, different error:
https://i.imgur.com/TsSqp1g.png

I hope you can work with this, because I can't do more to prove that the module
won't load.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 217978] dhclient: Support supersede statement for option 54

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217978

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable12?,
   ||mfc-stable11?
   Assignee|b...@freebsd.org|n...@freebsd.org
 CC||n...@freebsd.org
   Keywords|patch   |easy, needs-qa
Summary|Dhclient does not support   |dhclient: Support supersede
   |supersede statement for |statement for option 54
   |option 54   |
 Status|New |Open

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 166724] if_re(4): watchdog timeout

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

--- Comment #69 from Alex Dupre  ---
(In reply to László Károlyi from comment #68)

If you followed the pkg-message instructions you should simply see the
following lines in dmegs:

re0:  port 0xe000-0xe0ff mem
0x91104000-0x91104fff,0x9110-0x91103fff irq 20 at device 0.0 on pci2
re0: Using Memory Mapping!
re0: Using 1 MSI-X message
re0: ASPM disabled
re0: version:1.96.04

instead of:

re0:  port
0xe000-0xe0ff mem 0x91104000-0x91104fff,0x9110-0x91103fff irq 20 at device
0.0 on pci2
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: ASPM disabled
re0: Chip rev. 0x5400
re0: MAC rev. 0x0010


In particular you should check the "version:1.06.04" line.


If you want to manually load it from the loader, then you have to load the
kernel before:

load /boot/kernel/kernel
load /boot/modules/if_re.ko

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"