From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> From: Lyndon Nerenberg Date: Sun, 12 Feb 2006 18:56:17 -0800 Subject: [9fans] Bogus shared IRQ on Dell D610 Topicbox-Message-UUID: fddf7452-ead0-11e9-9d60-3106f5b1d025 A bit more info on the 3C589 problems I'm having on my D610 laptop. During boot the kernel says: ... ELCR: 0E80 #y0: 2 slot Intel 82365SL: port 0x3E0 IRQ 5 #y1: 2 slot Intel 82365SL: port 0x3E0 IRQ 5 8259enable: irq 5 shared but not level intrenable: couldn't enable irq 5, tbdf 0xFFFFFFFF for i82365.1 #I0: xcvr10BaseT 3C589 I0: 3C589: 10 Mbps port 0x240 irq 10: 00104bdf06a8 ... The kernel is getting confused about #y1, which makes sense, because there is no #y1. This laptop only has a single card slot. The 589 card is visible, and both /net/ether0/stats and ifstats are reporting traffic in both directions (provoked by trying the DHCP dance with ip/ ipconfig), it just seems as though the received data isn't being handed up to the user mode process. I'm puzzled whether this is because of the irq 5 confusion. The card claims it's interrupting on irq 10, and the driver claims to be receiving (good) frames. Should irq 5 even matter after the kernel finds the device and (apparently successfully) maps it's memory and sets up the interrupt routing? --lyndon