new interrupt code: panic when going multiuser

John Baldwin jhb at
Tue Nov 4 10:46:56 PST 2003

On 04-Nov-2003 Bruce Evans wrote:
> On Tue, 4 Nov 2003, John Baldwin wrote:
>> On 04-Nov-2003 Lukas Ertl wrote:
>> > On Tue, 4 Nov 2003, Lukas Ertl wrote:
>> >
>> >> I somehow can't get at a good vmcore :-(.  But I found out that the
>> >> machine boots fine in "Safe Mode", where DMA and hw.ata.wc is turned off.
>> >
>> > Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine.  Could there
>> > be some issue with ATAng + new interrupt code?
>> Can you provide a dmesg please?  There may be a weird issue with
>> some PPro's for example that I haven't been able to test.
> I have noticed the following problems with the new interrupt code so far:
> - it conflicts with a few thousand lines of local changes.
> - yesterday's backup kernels which I preserved to run benchmarks with
>   all hang at boot time while probing atapicam devices.  Backing out
>   rev.1.23 of ata-lowlevel.c fixes the hang, but I didn't back up
>   yesterday's sources so it will take some work to regenerate working
>   versions of yesterday's kernels.
> The following is without the local changes:
> - cyintr(int unit) panics becauase it is passed a pointer to somewhere.
>   I think all compat_isa devices are broken for unit 0 because unit 0
>   is represented by a null pointer.

Ah, ok.  Yes, this is a semantic change.  To try and support clock interrupts,
a fast handler that passes a NULL argument will get a pointer to the intrframe
as its argument.  I got the idea via sparc64 from jake at .  Perhaps something
can be faked up in the compat_isa shims to fix this.

Please try

> - on a BP6, UP kernels without apic work except for cyintr(), but SMP
>   kernels have problems with missing interrupts for ata devices and hang
>   at boot time.

Is this related to the ata-lowlevel commit you mentioned above?


John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve!"  -

More information about the freebsd-current mailing list