Date: Sat, 18 Apr 1998 21:58:42 -0500 (CDT) From: Alex Nash <nash@mcs.net> To: rhh@ct.picker.com Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: Bt848: no IRQ Message-ID: <199804190258.VAA00634@nash.pr.mcs.net> In-Reply-To: <19980418212749.A5653@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <smp@csn.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804190258.VAA00634>