Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/179299 net[igb] Intel X540-T2 - unstable driver a kern/179264 net[vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net[arp] arp rejecting not working o kern/178782 net[ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net[run] kernel panic due the problems with run driver o kern/178472 net[ip6] [patch] make return code consistent with IPv4 co o kern/178116 net[ipfilter] [panic] Kernel panic: general protection fa o kern/178079 net[tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 netFreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net[xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net[bridge] Problem with bridge firewall with trunk ports o kern/177417 net[ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net[igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net[jme] JMC25x 1000baseT establishment issues o kern/177366 net[ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net[netinet] [patch] Wrong control used to return TOS o kern/177194 net[netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net[igb] igb drops ethernet ports 2 and 3 o kern/176884 net[re] re0 flapping up/down o kern/176671 net[epair] MAC address for epair device not unique o kern/176596 net[firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net[ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net[netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net[kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net[kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net[netgraph] page fault in netgraph o kern/176167 net[ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net[lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net[em] [patch] flow control systcl consistency for em dr o kern/176026 net[tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 netppp(8): logic issue o kern/175864 net[re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net[amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 netno ethernet detected on system with EG20T PCH chipset o kern/175267 net[pf] [tap] pf + tap keep state problem o kern/175236 net[epair] [gif] epair and gif Devices On Bridge o kern/175182 net[panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net[tcp] will there miss a FIN when do TSO? o kern/174959 net[net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net[net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net[route] Interface routes are broken o kern/174851 net[bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net[bxe] [patch] bxe driver does not receive multicasts o kern/174849 net[bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net[tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net[gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net[tcp] TCP fast retransmit feature works strange o kern/173871 net[gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net[tun] tun(4) stays opened by PID after process is term o kern/173201 net[ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net[em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net[patch] data type size problem in if_spppsubr.c o kern/172895 net[ixgb] [ixgbe] do not properly determine link-state o kern/172683 net[ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net[netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net[panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net[ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net[bce] [panic] bce related kernel panic o kern/171711 net[dummynet] [panic] Kernel panic in dummynet o kern/171532 net[ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net[ndis] undocumented d
Re: kern/179299: [igb] Intel X540-T2 - unstable driver
The following reply was made to PR kern/179299; it has been noted by GNATS. From: Maxim Bourmistrov To: bug-follo...@freebsd.org, sy...@prisjakt.nu Cc: Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver Date: Mon, 10 Jun 2013 13:32:32 +0200 I was able to reproduce this issue on one of two identical machines, but = this is not 100% possible. However I was able to crash this machine, while trying to reproduce, = with the following stack trace. Thus no longer sure if my original problem IS cksum6/tso6 related. Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor write data, page not present instruction pointer=3D 0x20:0x805a220c stack pointer =3D 0x28:0xff917c839910 frame pointer =3D 0x28:0xff917c8399d0 code segment =3D base 0x0, limit 0xf, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process=3D 12 (irq283: ix0:que 0) trap number=3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0x80955276 at kdb_backtrace+0x66 #1 0x8091c5ee at panic+0x1ce #2 0x80cab720 at trap_fatal+0x290 #3 0x80caba81 at trap_pfault+0x211 #4 0x80cac034 at trap+0x344 #5 0x80c953c3 at calltrap+0x8 #6 0x805a28e6 at ixgbe_msix_que+0x86 #7 0x808ed80d at intr_event_execute_handlers+0xfd #8 0x808eeffe at ithread_loop+0x9e #9 0x808ea49f at fork_exit+0x11f #10 0x80c958ee at fork_trampoline+0xe Uptime: 13m13s //maxim= ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] multiple instances of ipfw(4)
Hello, reviving this old thread since i had time to bring the patch to FreeBSD 10 and unified the whole controlling under ipfw(8) binary. For reminder, the patch located at [1] provides multiple instances for ipfw(4). Basically you can control which interfaces belong to which context/ruleset to make maintaining easier. Also it gives more flexibility in general to ipfw(4) for various scenarios. It works by initializing a context of ipfw(4) and assigning specific interfaces explicitly by administrator to each instance. The context is not lost even on interface destruction and recreation, based on interface name match. Upon entering ipfw(4) processing the configured context/instance for that interface is selected if none no filtering is done. Most of the patch is rather straight forward and only some intrusive changes to ipfw NAT KPI, in kernel implementation is done to remove a global variable referring to the active instance and passing it explicitly. You can create a instance of ipfw by running: ipfw zone 1 create Add a member with ipfw zone 1 madd em0 ipfw zone 1 madd vlan0 Remove members with ipfw zone 1 mdel em0 Also destroy an instance by: ipfw zone 1 destroy All the other operations on ipfw(4) will be the same as before just require the -x $context argument added for each of them. The patch uses all the IP_FW3 option commands to avoid changes in other areas apart ipfw(4) related sources. Any objections on pushing this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATH] ALTQ(9) codel algorithm implementation
Hello, at location [1] can be found a patch for Codel[3] algorithm implementation. Triggered by a mail to the mailing lists[2] of OpenBSD i completed the implementation for FreeBSD. It allows to use codel as the single configured discipline on an interface. Also it can be used as a sub discipline of existing queueing disciplines already present. The work has been tested and confirmed working without issues in pfSense. Any objections on pushing this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/altq_codel.diff [2] http://permalink.gmane.org/gmane.os.openbsd.tech/29745 [3] http://www.bufferbloat.net/projects/codel/wiki -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] CARP using rw locks and unified timer
Hello, at the location [1] is a patch for making carp(4): - use rw locks - unify the timers in carp to a single one for accuracy and predictability This patch has been tested in pfSense for a long time and recently it has been moved to FreeBSD 10. It also fixed some races and LORs present in the whole stack especially with bridge interfaces. Any objections to merging this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/carp_livelock_fixes.diff -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] dummynet(4) patch for pf(4)
Hello, the patch at location [1] implements support for dummynet into pf(4). The patch has been tested and confirmed working without issues into pfSense. Any objections to integrating this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/dummynet.RELENG_10.diff -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] dummynet(4) patch for pf(4)
On Mon, Jun 10, 2013 at 03:45:01PM +0200, Ermal Lu?i wrote: > Hello, > > the patch at location [1] implements support for dummynet into pf(4). > > The patch has been tested and confirmed working without issues into pfSense. > > Any objections to integrating this into FreeBSD? for the dummynet/ipfw part i have no objection -- this is only a one-line change to sys/netpfil/ipfw/ip_dn_io.c For the pf part sys/netpfil/pf/pf.c, there are two huge macros PACKET_UNDO_NAT() and PACKET_REDO_NAT() which really look ugly. It would really make sense to change them into functions (they already do some substantial work so the saving of one function call is negligible). There is also some questionable indentation see the calls to m_copyback() in PACKET_REDO_NAT() Some extra braces around if/else blocks would help immensely. cheers luigi > [1] > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/dummynet.RELENG_10.diff > > -- > Ermal > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] multiple instances of ipfw(4)
On Mon, Jun 10, 2013 at 3:30 PM, Ermal Luçi wrote: > Hello, > > reviving this old thread since i had time to bring the patch to FreeBSD 10 > and unified the whole controlling under ipfw(8) binary. > > For reminder, the patch located at [1] provides multiple instances for > ipfw(4). > Basically you can control which interfaces belong to which context/ruleset > to make maintaining easier. > > ... > Any objections on pushing this into FreeBSD? > > > [1] > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff > > > if i understand well, this has no runtime overhead as the ifp has the index of the context it refers to ? Or you need an additional IPFW_CTX_RLOCK() ? Comments on the control/config path: - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might overflow the temporary buffer when building the list. You compute the length under rlock, release the lock, malloc(), then fill the list without checking if the total size is still correct. This kind of code is terribly boring to write, but essentially you need a bound check in the second loop and possibly retry if you notice that you need more memory. "ipfw show" addresses the problem by failing and requesting the user application to pass a larger buffer. - similarly, how do you guarantee that deleting a context while a packet is under processing does not cause dereferencing a NULL pointer ? cheers luigi while > -- > Ermal > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Gratuitous ARP increasing mbufs
Hi, I am running a system on FreeBSD 9.1-RELEASE. I have a device on the network which is sending gratuitous ARP messages (used by a wireless mesh network for a "bridge-loop avoidance" protocol) every 10 seconds. This causes the mbuf clusters to slowly increase on FreeBSD, until the maximum is reached, which disables the networking. I am running netstat -m to keep track of the mbuf run away / leak. My understanding is that mbufs are allocated to hold these messages, but since they are "replys" they are never used. I am now using ipfw, to drop all ARP messages with the following rule: ipfw add 999 deny layer2 mac-type arp MAC ff:ff:ff:ff:ff:ff ac:86:74:02:8a:ff via vte0 It solves the problem. Luckily there are only offending gratuitous ARP messages from this MAC address, so I don't loose any ARP messages that I would need. I believe this might be a bug in FreeBSD. Shouldn't these gratuitous ARP packets be handled in a more elegant way? The increasing mbufs doesn't seem right. A timeout on these mbufs or a maximum number of mbufs that can be allocated for this type of packet might solve this problem. I just wanted to bring this to the developers attention. Thanks very much, Greg The details of the ARP message are as follows (from Wireshark): No. Time SourceDestination Protocol Length Info 2450 4642.007546000 OpenMesh_02:8a:ff Broadcast ARP 60 Gratuitous ARP for 0.0.0.0 (Reply) Frame 2450: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) ..1. = LG bit: Locally administered address (this is NOT the factory default) ...1 = IG bit: Group address (multicast/broadcast) Source: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) Address: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) ..0. = LG bit: Globally unique address (factory default) ...0 = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: Address Resolution Protocol (reply/gratuitous ARP) Hardware type: Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (2) [Is gratuitous: True] Sender MAC address: 43:05:43:05:00:00 (43:05:43:05:00:00) Sender IP address: 0.0.0.0 (0.0.0.0) Target MAC address: ff:43:05:02:a2:0c (ff:43:05:02:a2:0c) Target IP address: 0.0.0.0 (0.0.0.0) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] multiple instances of ipfw(4)
On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > > > > On Mon, Jun 10, 2013 at 3:30 PM, Ermal Luçi wrote: > >> Hello, >> >> reviving this old thread since i had time to bring the patch to FreeBSD 10 >> and unified the whole controlling under ipfw(8) binary. >> >> For reminder, the patch located at [1] provides multiple instances for >> ipfw(4). >> Basically you can control which interfaces belong to which context/ruleset >> to make maintaining easier. >> >> > ... > > > >> Any objections on pushing this into FreeBSD? >> >> >> [1] >> >> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff >> >> >> > > if i understand well, this has no runtime overhead as the ifp has > the index of the context it refers to ? > Or you need an additional IPFW_CTX_RLOCK() ? > Theoretically you would need for correctness the read lock. It has never been hit in pfSense hence no further investigation on it has been done. It can be made even a read mostly lock or to prevent the race the write lock of the pfil hooks so no packets are passed through?! > > Comments on the control/config path: > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > overflow the temporary buffer when building the list. You compute > the length under rlock, release the lock, malloc(), then fill the > list without checking if the total size is still correct. > This kind of code is terribly boring to write, but essentially > you need a bound check in the second loop and possibly > retry if you notice that you need more memory. > "ipfw show" addresses the problem by failing and requesting the > user application to pass a larger buffer. > Yeah that probably can be fixed. During implementation it was considered enough rare operation to not justify further thought. > > - similarly, how do you guarantee that deleting a context while > a packet is under processing does not cause dereferencing a > NULL pointer ? > Presently, none, but as i said during instance/context operation a write lock on the pfil hook can be taken? That should prevent the issue altogether and remove the requirement of having to read lock the fast path. If you agree with the above i can redo the patch again with the above changes for review? > cheers > luigi > > while >> -- >> Ermal >> >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > > > > -- > -+--- > Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/. Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -+--- > -- Ermal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] multiple instances of ipfw(4)
On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: ... > > if i understand well, this has no runtime overhead as the ifp has > > the index of the context it refers to ? > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > Theoretically you would need for correctness the read lock. > It has never been hit in pfSense hence no further investigation on it has > been done. > It can be made even a read mostly lock or to prevent the race the write > lock > of the pfil hooks so no packets are passed through?! adding another lock (even just a read lock) around invocations is undesirable in my opinion. I'd rather check if there is already some other lock which is already held so we can use it to protect the list of contexts. > > Comments on the control/config path: > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > overflow the temporary buffer when building the list. You compute > > the length under rlock, release the lock, malloc(), then fill the > > list without checking if the total size is still correct. > > This kind of code is terribly boring to write, but essentially > > you need a bound check in the second loop and possibly > > retry if you notice that you need more memory. > > "ipfw show" addresses the problem by failing and requesting the > > user application to pass a larger buffer. > > > > Yeah that probably can be fixed. > During implementation it was considered enough rare operation to not > justify further thought. well, unlike the previous problem (locking), this has a very simple fix and no performance implications so there are really no excuses... > If you agree with the above i can redo the patch again with the above > changes for review? i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing comment in the place where the context is being accessed. Or if you can find another lock to recycle, fine. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
Hi John and Pyun,
Ok got the new kernel installed and tested. Yes it works! :-) Maybe that
will also fix a simular problem with the sun cards (cas[03]), except I
don't see a define like that in if_cas.c. Suggestions?
Thanks,
Clif
John Baldwin wrote:
On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote:
On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote:
Sorry for the confusion Pyun,
I started looking at it in the context of pfsense, but they rejected my
bug report which was understandable because it's an upstream issue. They
suggested I resubmit it to you guys if I could reproduce it. So I booted
FreeBSD and lo and behold the same two ports failed in exactly the same
Ok, I'd like to fix that.
Hmmm, the dc(4) driver is using the I/O port BARs rather than the
memory BARs for its registers and this bug seems to be that the dc(4)
device can't properly access its registers on dc0 and dc1 on the
Atom box. The one thing I see is that the BIOS on the Atom box assigns
addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses
conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS
is more careful to avoid these ranges.
I think the fix is that I need to fix the PCI-PCI bridge to reject these
resource ranges if the ISA enable bit is set in the bridge's control
register. However, for the time being you can change dc(4) to use the
memory BAR instead of the I/O port BAR as a workaround:
Index: if_dc.c
===
--- if_dc.c (revision 251132)
+++ if_dc.c (working copy)
@@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$");
#include
#include
-#defineDC_USEIOSPACE
+//#define DC_USEIOSPACE
#include
If this fixes it then I can take this PR as a test case for handling the ISA
enable bit in the PCI-PCI bridge code.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
On Mon, Jun 10, 2013 at 12:13:11PM -0700, Mr. Clif wrote:
> Hi John and Pyun,
>
> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that
Thanks, probably John can fix PCI-PCI bridge code.
> will also fix a simular problem with the sun cards (cas[03]), except I
> don't see a define like that in if_cas.c. Suggestions?
Cassini does not support I/O port BARs so I guess you're seeing
different issue. Would you start a new thread that explains cas(4)
issues you're suffering from?
>
> Thanks,
> Clif
>
>
> John Baldwin wrote:
> >On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote:
> >>On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote:
> >>>Sorry for the confusion Pyun,
> >>>
> >>>I started looking at it in the context of pfsense, but they rejected my
> >>>bug report which was understandable because it's an upstream issue. They
> >>>suggested I resubmit it to you guys if I could reproduce it. So I booted
> >>>FreeBSD and lo and behold the same two ports failed in exactly the same
> >>Ok, I'd like to fix that.
> >Hmmm, the dc(4) driver is using the I/O port BARs rather than the
> >memory BARs for its registers and this bug seems to be that the dc(4)
> >device can't properly access its registers on dc0 and dc1 on the
> >Atom box. The one thing I see is that the BIOS on the Atom box assigns
> >addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses
> >conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS
> >is more careful to avoid these ranges.
> >
> >I think the fix is that I need to fix the PCI-PCI bridge to reject these
> >resource ranges if the ISA enable bit is set in the bridge's control
> >register. However, for the time being you can change dc(4) to use the
> >memory BAR instead of the I/O port BAR as a workaround:
> >
> >Index: if_dc.c
> >===
> >--- if_dc.c (revision 251132)
> >+++ if_dc.c (working copy)
> >@@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$");
> > #include
> > #include
> >
> >-#define DC_USEIOSPACE
> >+//#define DC_USEIOSPACE
> >
> > #include
> >
> >
> >If this fixes it then I can take this PR as a test case for handling the
> >ISA
> >enable bit in the PCI-PCI bridge code.
> >
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
Is there any down side to using that dc fix in pfsense for now?
Yes, I would like to have time to submit the cas bug as well. Maybe in
the next week but probably by august I hope. ;-)
Thanks for your help,
Clif
YongHyeon PYUN wrote:
On Mon, Jun 10, 2013 at 12:13:11PM -0700, Mr. Clif wrote:
Hi John and Pyun,
Ok got the new kernel installed and tested. Yes it works! :-) Maybe that
Thanks, probably John can fix PCI-PCI bridge code.
will also fix a simular problem with the sun cards (cas[03]), except I
don't see a define like that in if_cas.c. Suggestions?
Cassini does not support I/O port BARs so I guess you're seeing
different issue. Would you start a new thread that explains cas(4)
issues you're suffering from?
Thanks,
Clif
John Baldwin wrote:
On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote:
On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote:
Sorry for the confusion Pyun,
I started looking at it in the context of pfsense, but they rejected my
bug report which was understandable because it's an upstream issue. They
suggested I resubmit it to you guys if I could reproduce it. So I booted
FreeBSD and lo and behold the same two ports failed in exactly the same
Ok, I'd like to fix that.
Hmmm, the dc(4) driver is using the I/O port BARs rather than the
memory BARs for its registers and this bug seems to be that the dc(4)
device can't properly access its registers on dc0 and dc1 on the
Atom box. The one thing I see is that the BIOS on the Atom box assigns
addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses
conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS
is more careful to avoid these ranges.
I think the fix is that I need to fix the PCI-PCI bridge to reject these
resource ranges if the ISA enable bit is set in the bridge's control
register. However, for the time being you can change dc(4) to use the
memory BAR instead of the I/O port BAR as a workaround:
Index: if_dc.c
===
--- if_dc.c (revision 251132)
+++ if_dc.c (working copy)
@@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$");
#include
#include
-#defineDC_USEIOSPACE
+//#define DC_USEIOSPACE
#include
If this fixes it then I can take this PR as a test case for handling the
ISA
enable bit in the PCI-PCI bridge code.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
On Mon, Jun 10, 2013 at 06:26:34PM -0700, Mr. Clif wrote: > Is there any down side to using that dc fix in pfsense for now? If dc(4) works as expected there is no reason not to use memory BARs. Generally using memory BARs is more efficient. Many old PCI controllers used to have bugs with memory BARs so driver used safer I/O port BARs. > > Yes, I would like to have time to submit the cas bug as well. Maybe in > the next week but probably by august I hope. ;-) > Ok. > Thanks for your help, > Clif ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
