Re: Enabling sio2 in 5.x

From: Aaron Heth (rev_at_rev.shadonet.com)
Date: 03/30/04 

Date: 30 Mar 2004 13:36:26 -0800

Hey, I'm just surprised to see a reply this soon, even a reply at all!
 5.x is a bit different, the kernel is just set to enabling the sio
device, but the configuration is in /boot/device.hints (the handbook
even says this). I've found the line where it says sio2.disabled =
"true" and taken it out, and it indeed does try to load sio2, but like
I said I get the error message. Are there any other common IRQs for
COM3? I think I'll try searching around a bit since I don't know much
about IRQs in general.

Ack, living out in the middle of the country is horrible. Wish my
cable company would come around and lay some lines so I can get back
to broadband. :)

By the way, thanks for the help Ditch.

"Ditch Brodie" <dbroadie@msn.com> wrote in message news:<qL3ac.5113$yN6.2632@newsread2.news.atl.earthlink.net>...
> I feel your pain brother...! But that's newsgroups for you. Many times just
> someone with a half baked idea as a resolution, so here goes my undercooked
> theory:
>
> In FreeBSD-4.x and earlier you have to compile the support for COM3 into
> your kernel. I've run FreeBSD since 2.2.5 and always had to do this. I know
> 5.x is a whole nother kind of smoke, but if that's the case, you will need
> to go through the recompile of your kernel to get access to COM3. IRQ 5 is a
> typical setting for COM3 but it's not the only one you could use. You can
> set the IRQ in the kernel config file also.
>
> PCI is also a different thing when dealing with IRQ's and such. I know that
> it's hard to make PCI modems work with FreeBSD or Linux but the old ISA's do
> well as do external modems that work on COM1 or COM2. FreeBSD's generic
> kernel comes with support for these two ports by default. But COM3 and COM4
> you must recompile for.

Relevant Pages

  • Re: RT patch acceptance
    ... > with user-mode execution as the only realtime service. ... time from irqs, and in turn it can't provide syscalls to avoid risking ... For preempt-RT to be equivalent to RTAI, the "rest of the kernel" will ...
    (Linux-Kernel)
  • Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path
    ... the bug or side-effect that made the difference: via enabling irqs we ... wrong - it's the worst thing a crashing kernel can do. ... NMI context without really having to exit it in the kernel code flow? ... the kexec on panic path more robust so that we can take crash dumps in ...
    (Linux-Kernel)
  • Re: [PATCH] PCI: Add pci shutdown ability
    ... >> spin with irqs off for a couple of seconds so the DMA and IRQs stop. ... >> crashed kernel. ... > trouble if a device without a driver is generating requests. ... So this shouldn't be a problem with interrupts ...
    (Linux-Kernel)
  • Re: amd5536udc interrupts bug
    ... irqs, and to remove the IRQF_SHARED flag from the request_irqcall. ... That will bust any other hardware that tries to share the interrupt. ... kernel, if only to quickly mark the driver as "known bad with shared irqs" to ...
    (Linux-Kernel)
  • Re: VMware, x86_64 and 2.6.21.
    ... that code is not part of the kernel or any kernel module. ... Nevertheless, since we must distinguish between software IRQs and hardware IRQs, we must find vectors that do not collide with the set of ... Now you can set aside a fixed number of IRQs to be used for software IRQs at boot time, ... There are cases where this would be a useful feature for us; being able to issue IPIs directly to a hypervisor mode CPU would be a significant speedup. ...
    (Linux-Kernel)