Hello, Not sure if this should be a follow up to problem report 179033 or not, but the patch to the dc driver seems to prevent the detection of other Nics when there are dc boards in the system. Test setup is exactly the same as in 179033. The behavior under Linux would also be the same. Under BSD, when there are dc cards in the system it rarely detects the native re nic on the mother board when booting. When it is detected it often crashes at the instant it prints the nic information line, though that is hard to reproduce. I have attached some diagnostic output of dmesg, ifconfig, and others, both with and without the dc quadport cards. Fix: Probably something in the patch submitted for PR 179033 is preventing the detection of the re hardware, it was always detected before. Patch attached with submission follows: How-To-Repeat: Boot the Atom D510MO Board with dc chipset quad port card(s) as in PR 179033
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Well I guess we were over optimistic on PR 179033. Yes I can get some of the Nics to work some of the time but mostly they don't work. They DO list the correct mac addresses and Status lines though, so that is an improvement. If I have just one quad port card installed then dc3 works most often, then dc1. dc0 and dc2 I'm not sure I ever saw working. Even if an interface worked for a bit it often stops after a while. Id'e be happy to run some tests if anyone has some patches for me to try. Clif
On 04/30/2014 09:12 AM, John Baldwin wrote: > On Tuesday, April 29, 2014 7:42:29 pm Mr. Clif wrote: >> Hi Guys, >> >> I've been playing with the new patch, and found a few problems that I >> posted in PR 188897: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=188897 >> >> and this one is about another quad port card in the same Atom MoBo: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=188899 >> >> I would be happy to test any new fixes you want me to try. > Can you disable agp and see if that fixes things? (hint.agp.0.disabled=1 at > the loader prompt) > On 05/01/2014 09:27 AM, Mr. Clif wrote: > Ok, > > sorry about the delay, now that I'm set up again the turnaround time > should be a lot faster. > > At the loader prompt I typed: > > set hint.agp.0.disabled=1 > boot > > After a lot of testing, the only possible difference I can see is that > the re0 interface is always? there when the agp is disabled and not > always there by default. By the way, this board doesn't have an AGP > port. Oh and I only checked the dc board, since it didn't work I > didn't go on to the sun board. :-) > > Clif > On 05/08/2014 09:10 AM, John Baldwin wrote: > On Wednesday, May 07, 2014 6:37:59 pm Mr. Clif wrote: >> Ok sorry I didn't get anywhere with the AGP experiment. I guess I'll put >> the machine away until you have other things for me to try. > Sorry, I have been focusing on another PCI bug people were running into that > was fixed earlier this week. However, that one involved resources failing to > allocate at all, so I'm not sure it is related to your case. Hmm, I see your > last issue was related to the special ISA decoding bits. Can you pick one > of the cases to focus on for now and capture a verbose dmesg from a HEAD > kernel? 'devinfo -r' and 'devinfo -u' output from the non-working kernel > would also be good. > On 05/10/2014 08:18 AM, Mr. Clif wrote: > Opps I almost didn't see this email, too much spam I guess :-( > > Sounds like you want me to get the latest from the FreeBSD repo. Could > you please give me the URL and commands for that so I don't get the > wrong code? > > By last issue do you mean PR 179033? > <http://www.freebsd.org/cgi/query-pr.cgi?pr=179033> Since that one was > closed I opened 188897 but they are both basically the same. > I'm not sure what symtoms the ISA decoding bits cause, to me it's just > that some of the NICs are unusable, but sure I can run those commands, > If you give me the git commands to get the correct code. I'll get the > non-working kernel now too. > > Clif
Here is the devinfo output for the failed system: root@BSD10:~ # uname -a FreeBSD BSD10 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 01:46:25 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 *************************************************************************** root@BSD10:~ # devinfo -r nexus0 npx0 apic0 I/O memory addresses: 0xfee00000-0xfee003ff ram0 I/O memory addresses: 0x0-0x8efff 0x90000-0x9ebff 0x100000-0xcee97fff 0xceebf000-0xcef47fff 0xcefbf000-0xceff0fff 0xcefff000-0xceffffff acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x72-0x73 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0x295-0x296 0x400-0x47f 0x500-0x53f 0x680-0x6ff I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xf8000000-0xfbffffff 0xfed14000-0xfed17fff 0xfed18000-0xfed18fff 0xfed19000-0xfed19fff 0xfed1c000-0xfed1ffff 0xfff00000-0xffffffff cpu0 p4tcc0 cpufreq0 cpu1 p4tcc1 cpufreq1 cpu2 p4tcc2 cpufreq2 cpu3 p4tcc3 cpufreq3 acpi_button0 pcib0 I/O ports: 0xcf8-0xcff pci0 hostb0 vgapci0 I/O ports: 0x30c0-0x30c7 I/O memory addresses: 0xd0000000-0xdfffffff 0xe0200000-0xe02fffff 0xe0300000-0xe037ffff agp0 I/O memory addresses: 0xe0000000-0xe0000fff pcib1 I/O ports: 0x2000-0x20ff 0x2400-0x24ff 0x2800-0x28ff 0x2c00-0x2cff I/O memory addresses: 0xe0100000-0xe01fffff pci1 re0 Interrupt request lines: 0x100 pcib1 I/O port window: 0x2000-0x20ff pcib1 prefetch window: 0xe0100000-0xe0100fff 0xe0104000-0xe0107fff miibus0 rgephy0 pcib2 pci2 pcib3 pci3 pcib4 pci4 uhci0 Interrupt request lines: 0x17 I/O ports: 0x3080-0x309f usbus0 uhub0 uhci1 Interrupt request lines: 0x13 I/O ports: 0x3060-0x307f usbus1 uhub2 uhci2 Interrupt request lines: 0x12 I/O ports: 0x3040-0x305f usbus2 uhub1 uhci3 Interrupt request lines: 0x10 I/O ports: 0x3020-0x303f usbus3 uhub3 ehci0 Interrupt request lines: 0x17 I/O memory addresses: 0xe0380400-0xe03807ff usbus4 uhub4 pcib5 I/O ports: 0x1000-0x10ff 0x1400-0x14ff 0x1800-0x18ff 0x1c00-0x1cff pci5 pcib6 pcib5 I/O port window: 0x1000-0x10ff 0x1400-0x14ff 0x1800-0x18ff 0x1c00-0x1cff pci6 dc0 Interrupt request lines: 0x15 pcib6 I/O port window: 0x1400-0x147f miibus1 lxtphy0 dc1 Interrupt request lines: 0x16 pcib6 I/O port window: 0x1480-0x14ff miibus2 lxtphy1 dc2 Interrupt request lines: 0x17 pcib6 I/O port window: 0x1080-0x10ff miibus3 lxtphy2 dc3 Interrupt request lines: 0x14 pcib6 I/O port window: 0x1000-0x107f miibus4 lxtphy3 isab0 isa0 pmtimer0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff ata0 Interrupt request lines: 0xe I/O ports: 0x1f0-0x1f7 0x3f6 ata1 Interrupt request lines: 0xf I/O ports: 0x170-0x177 0x376 atapci0 Interrupt request lines: 0x13 I/O ports: 0x30a0-0x30af 0x30b0-0x30b7 0x30b8-0x30bf 0x30c8-0x30cb 0x30cc-0x30cf I/O memory addresses: 0xe0380000-0xe03803ff ata2 ata3 acpi_sysresource0 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 atdma0 DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf atrtc0 Interrupt request lines: 0x8 I/O ports: 0x70-0x71 0x74-0x77 atpic0 I/O ports: 0x20-0x3d 0xa0-0xbd 0x4d0-0x4d1 npxisa0 I/O ports: 0xf0 attimer0 Interrupt request lines: 0x0 I/O ports: 0x40-0x43 0x50-0x53 acpi_sysresource1 atkbdc0 Interrupt request lines: 0x1 I/O ports: 0x60 0x64 atkbd0 uart0 Interrupt request lines: 0x4 I/O ports: 0x3f8-0x3ff uart1 Interrupt request lines: 0x3 I/O ports: 0x2f8-0x2ff hpet0 Interrupt request lines: 0x14 I/O memory addresses: 0xfed00000-0xfed03fff acpi_timer0 ACPI I/O ports: 0x408-0x40b *************************************************************************** root@BSD10:~ # devinfo -u Interrupt request lines: 0x0 (attimer0) 0x1 (atkbdc0) 0x3 (uart1) 0x4 (uart0) 0x5-0x7 (root0) 0x8 (atrtc0) 0x9 (acpi0) 0xa-0xd (root0) 0xe (ata0) 0xf (ata1) 0x10 (uhci3) 0x11 (root0) 0x12 (uhci2) 0x13 (atapci0) 0x13 (uhci1) 0x14 (dc3) 0x14 (hpet0) 0x15 (dc0) 0x16 (dc1) 0x17 (dc2) 0x17 (ehci0) 0x17 (uhci0) 0x100 (re0) DMA request lines: 0-3 (root0) 4 (atdma0) 5-7 (root0) I/O ports: 0x0-0xf (atdma0) 0x10-0x1f (acpi0) 0x20-0x3d (atpic0) 0x3e-0x3f (root0) 0x40-0x43 (attimer0) 0x44-0x4f (root0) 0x50-0x53 (attimer0) 0x54-0x5f (root0) 0x60 (atkbdc0) 0x61 ---- 0x62-0x63 (root0) 0x64 (atkbdc0) 0x65-0x6f (root0) 0x70-0x71 (atrtc0) 0x72-0x73 (acpi0) 0x74-0x77 (atrtc0) 0x78-0x7f (root0) 0x80 (acpi0) 0x81-0x83 (atdma0) 0x84-0x86 (acpi0) 0x87 (atdma0) 0x88 (acpi0) 0x89-0x8b (atdma0) 0x8c-0x8e (acpi0) 0x8f (atdma0) 0x90-0x9f (acpi0) 0xa0-0xbd (atpic0) 0xbe-0xbf (root0) 0xc0-0xdf (atdma0) 0xe0-0xef (root0) 0xf0 (npxisa0) 0xf1-0x16f (root0) 0x170-0x177 (ata1) 0x178-0x1ef (root0) 0x1f0-0x1f7 (ata0) 0x1f8-0x294 (root0) 0x295-0x296 (acpi0) 0x297-0x2f7 (root0) 0x2f8-0x2ff (uart1) 0x300-0x375 (root0) 0x376 (ata1) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (ata0) 0x3f7 (root0) 0x3f8-0x3ff (uart0) 0x400-0x47f (acpi0) 0x480-0x4cf (root0) 0x4d0-0x4d1 (atpic0) 0x4d2-0x4ff (root0) 0x500-0x53f (acpi0) 0x540-0x67f (root0) 0x680-0x6ff (acpi0) 0x700-0xcf7 (root0) 0xcf8-0xcff (pcib0) 0xd00-0xfff (root0) 0x1000-0x10ff (pcib5) 0x1100-0x13ff (root0) 0x1400-0x14ff (pcib5) 0x1500-0x17ff (root0) 0x1800-0x18ff (pcib5) 0x1900-0x1bff (root0) 0x1c00-0x1cff (pcib5) 0x1d00-0x1fff (root0) 0x2000-0x20ff (pcib1) 0x2100-0x23ff (root0) 0x2400-0x24ff (pcib1) 0x2500-0x27ff (root0) 0x2800-0x28ff (pcib1) 0x2900-0x2bff (root0) 0x2c00-0x2cff (pcib1) 0x2d00-0x2fff (root0) 0x3000-0x301f ---- 0x3020-0x303f (uhci3) 0x3040-0x305f (uhci2) 0x3060-0x307f (uhci1) 0x3080-0x309f (uhci0) 0x30a0-0x30af (atapci0) 0x30b0-0x30b7 (atapci0) 0x30b8-0x30bf (atapci0) 0x30c0-0x30c7 (vgapci0) 0x30c8-0x30cb (atapci0) 0x30cc-0x30cf (atapci0) 0x30d0-0xffff (root0) I/O memory addresses: 0x0-0x8efff (ram0) 0x8f000-0x8ffff (root0) 0x90000-0x9ebff (ram0) 0x9ec00-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xdffff (acpi0) 0xe0000-0xfffff (acpi0) 0x100000-0xcee97fff (ram0) 0xcee98000-0xceebefff (root0) 0xceebf000-0xcef47fff (ram0) 0xcef48000-0xcefbefff (root0) 0xcefbf000-0xceff0fff (ram0) 0xceff1000-0xceffefff (root0) 0xcefff000-0xceffffff (ram0) 0xcf000000-0xcfffffff (root0) 0xd0000000-0xdfffffff (vgapci0) 0xe0000000-0xe0000fff (agp0) 0xe0001000-0xe00fffff (root0) 0xe0100000-0xe01fffff (pcib1) 0xe0200000-0xe02fffff (vgapci0) 0xe0300000-0xe037ffff (vgapci0) 0xe0380000-0xe03803ff (atapci0) 0xe0380400-0xe03807ff (ehci0) 0xe0380800-0xf7ffffff (root0) 0xf8000000-0xfbffffff (acpi0) 0xfc000000-0xfebfffff (root0) 0xfec00000-0xfec000ff ---- 0xfec00100-0xfecfffff (root0) 0xfed00000-0xfed03fff (hpet0) 0xfed04000-0xfed13fff (root0) 0xfed14000-0xfed17fff (acpi0) 0xfed18000-0xfed18fff (acpi0) 0xfed19000-0xfed19fff (acpi0) 0xfed1a000-0xfed1bfff (root0) 0xfed1c000-0xfed1ffff (acpi0) 0xfed20000-0xfedfffff (root0) 0xfee00000-0xfee003ff (apic0) 0xfee00400-0xffefffff (root0) 0xfff00000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x72-0x73 (root0) 0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0x295-0x296 (root0) 0x400-0x407 (root0) 0x408-0x40b (acpi_timer0) 0x40c-0x47f (root0) 0x500-0x53f (root0) 0x680-0x6ff (root0) ACPI I/O memory addresses: 0xc0000-0xfffff (root0) 0xf8000000-0xfbffffff (root0) 0xfed14000-0xfed19fff (root0) 0xfed1c000-0xfed1ffff (root0) 0xfff00000-0xffffffff (root0) pcib1 I/O port window: 0x2000-0x20ff (re0) 0x2400-0x24ff (root0) 0x2800-0x28ff (root0) 0x2c00-0x2cff (root0) pcib1 memory window: pcib1 prefetch window: 0xe0100000-0xe0100fff (re0) 0xe0101000-0xe0103fff (root0) 0xe0104000-0xe0107fff (re0) 0xe0108000-0xe01fffff (root0) pcib2 I/O port window: pcib2 memory window: pcib2 prefetch window: pcib3 I/O port window: pcib3 memory window: pcib3 prefetch window: pcib4 I/O port window: pcib4 memory window: pcib4 prefetch window: pcib5 I/O port window: 0x1000-0x10ff (pcib6) 0x1400-0x14ff (pcib6) 0x1800-0x18ff (pcib6) 0x1c00-0x1cff (pcib6) pcib5 memory window: pcib5 prefetch window: pcib6 I/O port window: 0x1000-0x107f (dc3) 0x1080-0x10ff (dc2) 0x1400-0x147f (dc0) 0x1480-0x14ff (dc1) 0x1800-0x18ff (root0) 0x1c00-0x1cff (root0) pcib6 memory window: pcib6 prefetch window:
I would also need a verbose dmesg (so dmesg from 'boot -v') for both of your PRs. In particular, I need to see what the PCI-PCI bridge driver is doing under the hood to manage its windows. It seems odd to me that your BIOS is assigning prefetchable memory to the memory registers for these devices. One hack would be to force the re(4) driver to use its I/O bar instead of its memory bar (you can set the 'hw.re.prefer_iomap=1' tunable in loader.conf to test this). That would confirm that the issue is with the memory BAR.
Created attachment 151998 [details] a verbose dmesg listing with a dc quadport card on the PCI bus Here is dmsg output as requested. I used option 5 then 6 to turn on the verbose flag.
Created attachment 152106 [details] This is a verbose dmesg for another dc quadport card, a DFE-570TX
So I had missed that you had tried hint.agp.0.disabled=1 before and it fixed this when I re-read this recently. I suspect the re hint would also workaround this. The bug here is the same as one reported recently on net@ and I believe your other PR is a dupe. The problem is that when agp0 goes to allocate a random page of memory, it allocates a resource range that conflicts with the memory I/O windows already claimed by the PCI-PCI bridges on PCI bus 0. We move the window down for the first PCI-PCI bridge that re0 lives behind, but when we do, we move it such that it overlaps the window that the second bridge the quad-port card lives behind. As a result, I believe that some of the memory requests destined for re0 end up getting routed to one of the ports on the quad-port card instead confusing the driver. The second PCI-PCI bridge then probes and notices it is busted, so it moves its window down. If you were to force the re0 device to reattach at that point it would actually work fine, but there's currently not an easy way to do that. The real bug is that the PCI-PCI bridge I/O windows need to be accounted for and not conflicted with. There are a couple of ways to fix this, most of which aren't quite trivial: 1) Reserve the resources assigned to I/O windows just as we do for firmware-assigned BARs before probing any devices. This is probably what I would prefer, but it is unfortunately a bit messy because of the ISA-enable bit (the existing pci_pci driver has quite a bit of code to deal with this already and it would be a shame to duplicate). Also, the PCI bus driver doesn't currently "know" about the resources backing an I/O window the same way it knows about BARs. 1a) Like 1) but sidestep the ISA-enable ickiness by just applying this to memory windows. 2) Flesh out new-bus multipass for x86. This would cause the the PCI-PCI bridge drivers to probe and claim any resources before drivers like agp0 got a chance. This is not a small amount of work however. For now, hint.agp.0.disabled=1 should serve as a workaround for you for all of your cases I believe until I have time to develop and test a better fix.
Greetings, I just tried the hint.agp.0.disabled=1 again, and not surprisingly, I got the same results as before. Though I had also forgten what those where. ;-) to wit: Yes it does bring back the re0 interface, but the dc ports fail in exactly the same way as I described above. ie, about two of them work, sometimes only one. The patch seems to have fixed just the mac addresses and the link active sensing, and even though these work for all ports some (most?) ports still fail to get a dhcp lease. The bottom line is I can't use this as a workaround, sorry. At least it seems like you have a good understanding of the problem, too bad it's so hard to fix. Clif
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
*** Bug 188899 has been marked as a duplicate of this bug. ***
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.