I'm seeing some extremely odd behaviour on a system that runs the amd automounter and has an Adaptec-155-ATM card at interface en0. Configuration: The system in question has two Ethernet cards, one of which (fxp0) connects the system to our LAN, the other is used locally for experiments (de0). The system also has an Adaptec-155-ATM card at interface en0, which is *not* connected to anything yet. The system is currently running 4.0-STABLE, but I've seen the same behavior under 3.2-RELEASE as well: As long as I leave en0 unconfigured (ifconfig en0 says "en0: flags=800<SIMPLEX> mtu 9180"), everything is fine. If I put an ifconfig entry in rc.conf.local (e.g. ifconfig_en0="10.9.112.211 netmask 255.255.240.0 up"), the automounter fails to work. Note that amd (like all other network services) uses the hosts main interface (fxp0). Here's what I see at boot time, as soon as amd starts: Mar 30 14:27:12 mul /kernel: atm_rtrequest: RTM_RESOLVE request detected? Mar 30 14:27:12 mul /kernel: nfs send error 65 for server pid133@mul:/nfs Mar 30 14:27:12 mul /kernel: nfs send error 65 for server pid133@mul:/home amd fails, but the rest of the network services seem unaffected. Any ideas? Please let me know if you require more information, I'd be happy to poke around the system a bit. Fix: Workarounds: 1. If I manually configure en0 after the system has booted (and amd has started), I do not see any problems, i.e. amd continues to work. 2. If I replace the Adaptec card with an Efficient Networks ENI-155p card, amd also works fine; I do not see the messages above. (Unfortunately, we don't have enough of those.) How-To-Repeat: see above
State Changed From-To: open->feedback Is this problem still present on more recent releases?
Adding to the audit trail: In message <3DEA8F06.5040708@isi.edu>, Lars Eggert writes: >Ian Dowse wrote: >> Is this problem still present on more recent releases? >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=17775 > >We're not using the ATM cards anymore, so I can't confirm it.
kern/17775 can be closed, as -current has a reworked ATM driver that may fix this. (Plus, I no longer have the hardware this was an issue with.) Lars -- Lars Eggert <larse@isi.edu> USC Information Sciences Institute
State Changed From-To: feedback->closed Submitter requests PR be closed