I came across a RealTek network device (device id 0x8169) that doesn't work with memory mapped registers. Reverting to using IO space as is already being done for the 8169SC (0x8167) devices solved the problem. Patch is attached.
Created attachment 189913 [details] re 8169 fix
(In reply to aaron.styx from comment #1) Unfortunately, RT_DEVICEID_8169 is rather broad and there definitely are members of that family which are know to work just fine when using the SYS_RES_MEMORY-type BAR. What are the exact chip and MAC revisions as reported in the re(4) attach message that is failing for you? Please post all lines emitted by re(4) during attach so we also see all resources assigned. Also what exactly do you mean by "doesn't work"? In case this is an add-on card, have you tried it in a different kind of machine?
Created attachment 189996 [details] /var/log/messages re1 output After submitting the bug, I did some digging and saw how common this chip is, so I would agree that simply forcing all of them to use IO mapped registers is not the right solution. The attached is the relevant output of /var/log/messages. (Note that this is from a 10.1 Live CD). I clearly need to do some more testing with this. I'll try this card in a different machine, and I'd also like to compile with RE_DIAG to see if this is simply a known problem with this device, but that will take me a bit. I'm not sure if the 10.1 live cd build is compiled with this or not... As for the meaning of "doesn't work," I'm able to set the address and bring the device up with ifconfig, which reports the device is up and active. However, any attempts to ping another host on the network results in 'sendto: Host is down.' Wireshark shows no packets coming from the 1869 re device. Other network devices on this machine work as expected, so I know it's not a network issue. Setting hw.re.prefer_iomap=1 also works. The device works on Linux in this machine, though I haven't taken a close look at their driver yet, or figured out if they're using Memory or IO mapped registers.
Tested this card on an older machine and it worked fine with memory mapped registers. The problem system is with an Asus p8h67-m pro. Investigation ongoing...
^Triage: clear the now obsolete 'patch' keyword. To submitter: is this aging PR still relevant?
(In reply to Mark Linimon from comment #5) No, I never was able to figure out why this card/motherboard combination had a problem, and I have a local configuration workaround in case I ever need to use it again. I've not seen the issue anywhere else, so if nobody else has encountered this, I'd say the bug can be closed.
^Triage: apparently particular to one hardware setup.