From owner-freebsd-multimedia Sat Apr 18 19:59:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00312 for freebsd-multimedia-outgoing; Sat, 18 Apr 1998 19:59:19 -0700 (PDT) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA00293 for ; Sun, 19 Apr 1998 02:59:17 GMT (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.8/8.8.7) id VAA00634; Sat, 18 Apr 1998 21:58:43 -0500 (CDT) (envelope-from alex) Message-Id: <199804190258.VAA00634@nash.pr.mcs.net> Date: Sat, 18 Apr 1998 21:58:42 -0500 (CDT) From: Alex Nash Subject: Re: Bt848: no IRQ To: rhh@ct.picker.com cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <19980418212749.A5653@ct.picker.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18 Apr, Randall Hopper wrote: > Alex Nash: > |I tried sources from January 1, 1998 and October 7th, 1997 -- both > |acted the same as the latest -current sources: no video, no irq 12 > |visible in vmstat -i. > | > |Nothing else is using IRQ 12, and the BIOS is configured to assign IRQ > |12 to a PCI device. But let's suppose there was a hardware conflict > |(i.e. something else is using 12, but I don't have my kernel configured > |to use such a device). Wouldn't the fact that the device is identified > |as being on irq 12 mean that vmstat -i would report the presence of irq > |12? > > Not necessarily. If no interrupts have been issued by that device yet, I > believe it won't be in the list. For example, I have an ISA ethernet board > on IRQ 12 in my box and a modem on sio0/irq4. No net connected right now > and irq12/lnc0 is absent from my vmstat -i. irq4/sio0 is also absent > until I do something with my modem through sio0. Right you are again. From vmstat.c: while (--nintr >= 0) { --> if (*intrcnt) (void)printf("%-12s %8ld %8ld\n", intrname, *intrcnt, *intrcnt / uptime); Not doing this check produces a lot of extraneous output :) > |You've given me another idea though -- I'll juggle the PCI interrupts > |so that the BIOS assigns a different IRQ to the BT848. Maybe it'll > |start working if it uses another IRQ line. > > Worth a shot. No joy with this :( but... > |I have forgotten to mention one other possibly critical aspect of my > |kernel: SMP. I'll give a UP kernel a try to see if that makes a > |difference. > > If that's the ticket, Steve Passe would be a good guy to > poll. He's got a Bt848 card and runs SMP I believe. The good news: I booted the UP kernel and immediately saw my debug printfs in the bt848 interrupt handler. The bad news: The boot process hung. With the printfs in place, it appeared that the interrupt handler was being called continuously when the kernel hangs. Taking out the bt848 driver allows the boot process to succeed. I haven't tried the latest stuff Amancio checked in (rev 1.35), so that's my next stop. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message