Summary: | [cas] cas ethernet driver seems to have issues with some multiport card and mother board combinations | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | clif | ||||
Component: | kern | Assignee: | freebsd-net (Nobody) <net> | ||||
Status: | Closed DUPLICATE | ||||||
Severity: | Affects Some People | CC: | marius, ron, yongari | ||||
Priority: | Normal | Flags: | koobs:
mfc-stable10+
|
||||
Version: | 10.0-RELEASE | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
clif
2014-04-22 21:10:00 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). Hi, Are you able to provide the Sun part number of the network card, so that I can try and pick one up on eBay? Thanks, Gavin Hi Gavin, Yes its Sun P/N: 270-6738-07 and according to this Ebay add: http://www.ebay.com.au/itm/LOT-2-Sun-PCI-X-Quad-Port-GB-Ethernet-Adapter-QGEXPCI-501-6738-10-FREE-US-S-H-/151235315746 It's Sun FRU is: 501-6738-10, which is the number most people use for it but that number does not appear on the card itself. There is a sticker on it that reads 501673800XXXX. Other descriptors are: Qgexpci Quad Port Gigabit PCI / PCI-X. I suppose their is a small possibility that these are actually different cards, but the pictures seem to be identical. There is a great pfsense review about the 501-6738-10 here: http://www.glitchwrks.com/2012/08/03/Quad-Port-PCI-Ethernet-Roundup/ and here are some links on Ebay: http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=501-6738-10&_sop=15 http://www.ebay.com/itm/Sun-Microsystems-X4445A-501-6738-10-Quad-GigaSwift-PCI-X-Ethernet-Card-/371261403254?pt=LH_DefaultDomain_0&hash=item5670e77076 http://www.ebay.com/itm/like/331482697268?lpid=82&chn=ps etc... Thanks for looking into it! Clif Hey Gavin, Did you find a card yet? I could ship you one if needed. I just upgraded the BIOS in my two atom boards and I noticed that the upgrade program would list one bit of info which was differnent between them. Not sure it's useful but the D945GSEJT works fine with quadport cards and the D510MO is broken under FreeBSD. The Port Mapper table on the D945GSEJT (BIOS JT94510H.86A) is at F000:B350 and on the D510MO (BIOS MOPNV10N.86A) its at F000:BDD0 hope that helps, Clif I also experience this issue with the same mentioned card in the pfsense platform. I had been successfully using the quad port SUN NIC recommended here: http://www.glitchwrks.com/2012/08/03/Quad-Port-PCI-Ethernet-Roundup/ up through pfsense version 2.1.5 (RELENG_8_3). When pfsense moved to version 2.2 (releng/10.1)and since then the issue in this bug has required me to move to different network cards. I tested the previously working card in both an Atom based board and a Pentium 3 based system and experienced the same issues with each. I'd be glad to provide whatever additional information can help repair the cas driver in future versions releases. (In reply to Ron from comment #5) Do these Atom- and Pentium-3-based boards also run into PR 188897, i. e. agp0 getting a resource assigned that conflicts with the memory I/O windows of a PCI-PCI bridge in turn causing failure to use disjoint windows, like above? Created attachment 163275 [details]
Diagnostic info from Pentium 3 system
I uploaded the Diagnostic info from Pentium 3 system zip file. I don't know that I could tell you. I've reassembled the pentium 3 system and I've uploaded verbose dmesg and devinfo for the pentium 3 with the Quad Port Sun Gigabit card (model QGEXPCI, cas driver). I've also uploaded a verbose dmesg when a Sun Quad Port 10/100 card is installed (model QFEPCI, hme driver) in case it is of any use. The 10/100 card works fine. Additionally the system will crash after a couple minutes with the gigabit card installed if I have it hooked up to a live network connection. I've included the crash dumps from that as well. If I do not have the system plugged in to a live network connection then it will run apparently without issue. Please let me know if there's anything further I can do to assist, I'm glad to help if I can. (In reply to Marius Strobl from comment #6) Marius, I was able to see 'cannot disable RX MAC' message in the attachment so I vaguely guess it could be related with incomplete controller reset. It seems Linux sets soft_bit_0 of CAS_BIM_LDEV_OEN register to force a PCI reset for old Cassini before resetting other blocks. Another thing to try is to bypass MAC/DMA stop and directly issue reset in device attach phase. I guess some of those blocks may not be in sane state before the reset so relying on some bits of CAS_RX_CONF register shall trigger other issues. I was not able to find old cas(4) controller so I couldn't test above approach though. Marius do you other clue? (In reply to Pyun YongHyeon from comment #9) The MACs in question are Saturn ones rather than old Cassinis. Some of these former fail to disable the RX part on the first try, which isn't fatal and subsequent attempts succeed. That's why that message is under bootverbose. (In reply to Ron from comment #8) Thanks, that helped. However, what you are seeing is an entirely different problem than what this PR is about and as the original one actually not related to cas(4) either. A commit references this bug: Author: marius Date: Fri Nov 20 02:23:36 UTC 2015 New revision: 291088 URL: https://svnweb.freebsd.org/changeset/base/291088 Log: Avoid a NULL pointer dereference in bounce_bus_dmamap_sync() when the map has been created via bounce_bus_dmamem_alloc(). Even for coherent DMA - which bus_dmamem_alloc(9) typically is used for -, calling of bus_dmamap_sync(9) isn't optional. PR: 188899 (non-original problem) MFC after: 3 days Changes: head/sys/arm64/arm64/busdma_bounce.c head/sys/x86/x86/busdma_bounce.c *** This bug has been marked as a duplicate of bug 188897 *** A commit references this bug: Author: marius Date: Sun Dec 27 15:18:01 UTC 2015 New revision: 292775 URL: https://svnweb.freebsd.org/changeset/base/292775 Log: MFC: r286785, r291088, r291120 - Reformat x86 bounce buffer synchronization code to reduce indentation. No functional change. - Avoid a NULL pointer dereference in bounce_bus_dmamap_sync() when the map has been created via bounce_bus_dmamem_alloc(). Even for coherent DMA - which bus_dmamem_alloc(9) typically is used for -, calling of bus_dmamap_sync(9) isn't optional. [1] - Avoid a NULL pointer dereference in bounce_bus_dmamap_unload() when the map has been created via bounce_bus_dmamem_alloc(). In that case bus_dmamap_unload(9) typically isn't called during normal operation but still should be during detach, cleanup from failed attach etc. [2] PR: 188899 (non-original problem) [1] Submitted by: yongari [2] Changes: _U stable/10/ stable/10/sys/x86/x86/busdma_bounce.c A commit references this bug: Author: marius Date: Sun Dec 27 15:55:15 UTC 2015 New revision: 292778 URL: https://svnweb.freebsd.org/changeset/base/292778 Log: MFC: r286785, r291088, r291120 - Reformat x86 bounce buffer synchronization code to reduce indentation. No functional change. - Avoid a NULL pointer dereference in bounce_bus_dmamap_sync() when the map has been created via bounce_bus_dmamem_alloc(). Even for coherent DMA - which bus_dmamem_alloc(9) typically is used for -, calling of bus_dmamap_sync(9) isn't optional. [1] - Avoid a NULL pointer dereference in bounce_bus_dmamap_unload() when the map has been created via bounce_bus_dmamem_alloc(). In that case bus_dmamap_unload(9) typically isn't called during normal operation but still should be during detach, cleanup from failed attach etc. [2] PR: 188899 (non-original problem) [1] Submitted by: yongari [2] Changes: _U stable/9/sys/ stable/9/sys/x86/x86/busdma_machdep.c |