Date: Thu, 23 Oct 2003 10:17:10 -0700 From: "Kevin Oberman" <oberman@es.net> To: Ronald Klop <ronald-freebsd@klop.yi.org> Cc: freebsd-questions@freebsd.org Subject: Re: irq conflict laptop with 5.1-current Message-ID: <20031023171710.CD5CD5D07@ptavv.es.net> In-Reply-To: Message from Ronald Klop <ronald-freebsd@klop.yi.org> of "Thu, 23 Oct 2003 13:45:28 %2B0200." <oprxhux2e7hfcnru@outgoing.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Thu, 23 Oct 2003 13:45:28 +0200 > From: Ronald Klop <ronald-freebsd@klop.yi.org> > Sender: owner-freebsd-current@freebsd.org > > (Forwarding to -current; -questions and searching the net didn't give an > answer.) > > Hello, > > Running my laptop Compaq Armada 7400 with 5.1-CURRENT from about two days > ago. > The OHCI (USB) is on IRQ 11 and the PCCARD/CARDBUS also. > I now get a 'arp: unknown hardware address format (0x0000)' errors. > The 0x0000 can also be 0x2063 or oxfc00 or something else. > I think it's an irq conflict, but don't know how to give the different > device other irq's. > In 5.1-RELEASE it all worked ok. > Any idea's? Is my idea about the irq conflict right or is it something > else? > How van I solve this? It's something else. On recent FreeBSD releases, both V4 and V5, PCMCIA devices share the IRQ of the CardBus bridge. This is almost fixed. You can use a sysctl to use the old ISA interrupts which are not shared, but this is NOT a good idea. Try 'vmstat -i' and notice that the various network cards and many other PCI devices are not listed. Instead there is a 'mux' device which is the shared interrupt. PCI devices may use either the shared interrupt or a unique interrupt depending on how BIOS is configured, but the PCMCIA devices (either PCcard or CardBus) have to use the same IRQ as the bridge to which they are connected. The probable cause is a memory conflict (as indicated by the dmesg). This is being worked on, but, until it is fixed, you need to specify a start address for the card's memory. It must be greater then than the highest physical address of RAM and must not conflict with that of other devices. Add 'hw.cbb.start_memory="0x20000000"' to /boot/loader.conf and see if that fixes it. If it does not, try other values. (If you have large amounts of memory, you may need to start larger.) You MAY also need to add 'hw.pci.allow_unsupported_io_range="1"'. These need to be in loader.conf. sysctl.conf will not work as it loads too late in the boot sequence. You also have some major ACPI issues that may be causing the failure. If your system supports APM, try using that, instead. Or, at least boot with ACPI disabled (hint.acpi.0.disabled="1" in /boot/device.hints). If you want to use APM, load the module in /boot/loader.conf and enable it in /boot/device.hints. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031023171710.CD5CD5D07>