From owner-freebsd-hackers Sun Dec 13 13:12:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10828 for freebsd-hackers-outgoing; Sun, 13 Dec 1998 13:12:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10816 for ; Sun, 13 Dec 1998 13:12:10 -0800 (PST) (envelope-from listuser@netspace.net.au) Received: from d1o1.telia.com (root@d1o1.telia.com [195.67.240.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id WAA12988 for ; Sun, 13 Dec 1998 22:12:07 +0100 (CET) Received: from doorway.home.lan (t6o1p49.telia.com [195.67.241.109]) by d1o1.telia.com (8.8.8/8.8.5) with ESMTP id WAA24675 for ; Sun, 13 Dec 1998 22:11:58 +0100 (CET) Received: (from listuser@localhost) by doorway.home.lan (8.8.8/8.8.7) id VAA02521 for freebsd-hackers@FreeBSD.org; Sun, 13 Dec 1998 21:26:10 +0100 (CET) (envelope-from listuser) Date: Sun, 13 Dec 1998 21:26:10 +0100 (CET) From: List User Message-Id: <199812132026.VAA02521@doorway.home.lan> To: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Newsgroups: freebsd.hackers Path: root From: Stefan Esser Subject: Re: Adaptec ANA 6944A TX and/or PCI problem Content-Type: text/plain; charset=us-ascii Reply-To: se@FreeBSD.ORG Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.1/8.6.9) id MAA04896; Sun, 13 Dec 1998 12:43:35 +0100 (CET) To: Didier Derny , hackers Sender: owner-freebsd-hackers@FreeBSD.ORG Mail-Followup-To: Didier Derny , hackers@FreeBSD.ORG Organization: Private News Host Precedence: bulk Message-ID: <19981213124334.B564@mi.uni-koeln.de> X-Mailer: Mutt 0.93.2i References: Delivered-To: vmailer-hackers@freebsd.org X-Uidl: a377e1b112d9f4ebee5866708edb7eb9 X-Loop: FreeBSD.ORG Mime-Version: 1.0 In-Reply-To: ; from Didier Derny on Fri, Dec 11, 1998 at 09:52:20AM +0100 Cc: Stefan Esser Date: Sun, 13 Dec 1998 11:43:34 GMT On 1998-12-11 09:52 +0100, Didier Derny wrote: > I'm trying to use two Adaptec ANA 6944A TX (4 port) 10/100 BaseT board. > > - each board is working fine separately. > - both board are not working used simultanously > - Nothing special during the boot (dmesg seems ok) Please send me your dmesg output from a "-v" boot (verbose messages). > I made the following experience: > > ifconfig de0 inet 192.168.5.1 netmask 255.255.255.0 > ifconfig de4 inet 192.168.6.1 netmask 255.255.255.0 > > then I ping both networks simultaneously and got a message > telling me that the the ethernet / ip addresses were not > comming from the right source. > > ip from de0 with the ethernet address of de4 > > (ports were numbered from de0 to de3 for the first board > and from de4 to de7 for the second board) > > My guess: > > when the first board is initialized everything is ok, then when the > second board is initialized the io ports of the second board are allocated > at the same location than for the first board. This can be verified by looking at the map registers (address 0x10 to 0x24 in PCI config space, have to check which one is correct for the port map of the DEC Ethernet chip). But this information should also be provided by the verbose boot ... > I ran the adaptec diagnostics, he saw two boards effectively, > he saw the same io ports at the same adresses 0xc800, 0xc400... The boards can be distinguished in PCI config space (geographical addressing) no matter, what their map registers are set to. Did you try with memory mapped registers (kernel build option, see the driver sources, remove the definition of TULIP_IOMAPPED, the comment most probably applies to anxient PCI bridges ... > but I'm not sure if it's a relative or absolute address. > > The other possibility is a problem in the allocations of ports > in the if_de.c driver. > > It is sure that when trying to ping de0 alone, de4 is activated > > If it's a pci problem, is there any possibility to override the PCI > configuration to avoid this problem. While it is not really impossible to remap PCI devices, this is an ugly thing to do. Only the PCI BIOS knows about restrictions of the chip set or mainboard hardware, and it should have used that knowledge to assign valid addresses in the first place. (I.e. I'd rather not trust PCI BIOS services to return valid information for the kernel to fix things up, in such a case!) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message