Bug 17775

Summary: 4.0-STABLE: Adaptec-155-ATM at en0 causing amd problem
Product: Base System Reporter: larse <larse>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
smime.p7s none

Description larse 2000-04-03 20:50:01 UTC
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
Comment 1 iedowse freebsd_committer freebsd_triage 2002-12-01 01:03:34 UTC
State Changed
From-To: open->feedback


Is this problem still present on more recent releases?
Comment 2 iedowse 2002-12-01 22:41:56 UTC
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.
Comment 3 larse 2003-07-09 05:31:59 UTC
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
Comment 4 Kris Kennaway freebsd_committer freebsd_triage 2003-07-13 00:16:21 UTC
State Changed
From-To: feedback->closed

Submitter requests PR be closed