Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up

From: Harry Coin (harrycoin_at_qconline.com)
Date: 07/12/05

  • Next message: Scott Long: "Re: location of bioq lock" 
    Date: Tue, 12 Jul 2005 14:19:06 -0500
To: John Baldwin <jhb@FreeBSD.org>, freebsd-current@freebsd.org

    At 10:44 AM 7/12/2005 -0400, John Baldwin wrote:
    >Now, when ACPI is enabled, the
    >pnpmss driver doesn't probe the device IIRC?

    Both the mss_probe and pnpmss_probe routine are called in the ACPI case and
    in the ACPI disabled case. Let me help by providing proof from some
    edited short form commented dmesg excerpts from upstream postings using
    unmodified-except-for-debug-writes mss.c:

    In the case ACPI is enabled, you get:
    ...
    atpic: Programming IRQ9 as level/low
    mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find
    device
    pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh
    pnpmss_probe result 6
    mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find
    device
    pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh
    pnpmss_probe result 6
    ACPI timer: 0/6 0/4 0/5 0/6 0/6 0/4 0/6 0/6 0/6 0/5 -> 0
    Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
    acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
    mss_probe: bus acpi0 is probing device pcm0
    mss_probe: isa_get_logicalid() returned 0! -- non pnp probe FINDS the
    device, wrongly. Using the ISA_PNP_PROBE does the right thing here.
    mss_probe: no address given, try 0x530
    mss_detect - chip revision 0x0a
    mss_detect() - Detected CS4236
    pcm0: <CS4236> port 0x530-0x537 on acpi0
    device_attach: pcm0 attach returned 6
    mss_probe: bus acpi0 is probing device pcm1
    pnpmss_probe: bus acpi0 is probing device pcm1 lid 30ad041h, vid ffffffffh
    pnpmss_probe result 6
    pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
    <snip>...
    isa_probe_children: probing PnP devices
    mss_probe: bus isa0 is probing device pcm3
    pnpmss_probe: bus isa0 is probing device pcm3 lid 630eh, vid 3568630eh
    pnpmss_probe result 0
    pcm3: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1
    on isa0
    CS4236B X25 reg: ebh
    ...<snip and so on>

    In the case ACPI is not enabled, you get:

    ..isa_probe_children: probing PnP devices
    mss_probe: bus isa0 is probing device pcm0
    pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh
    pnpmss_probe result 0
    pcm0: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1
    on isa0
    CS4236B X25 reg: ebh
    ..
    Note that in the non-ACPI case, the non-pnp probe routine, mss_probe, when
    called by isa0 does the right thing and fails to accept the pnp
    device. The pnp probe routine correctly probes the device in this case.

    The question I can't get out of my head is this: When I change the mss.c
    code to use the routine the manual says non-PNP devices are supposed to
    use: ISA_PNP_PROBE -- all bootup operations are correct in both the ACPI
    and non ACPI case.

    Why doesn't that count as 'fixed, update mss.c and lets move on?'.

    Clearly the present code uses another function that doesn't work in the
    ACPI case. Shouldn't the investigation focus on what ISA_PNP_PROBE knows
    that the other call doesn't? ISA_PNP_PROBE in mss_probe works and matches
    the docs, the isa_get_whatziz doesn't work and is not accepted as correct
    practice in the docs. Maybe the doc writer has the answer. At any
    rate I don't get why this further investigation when an apparently
    'canonical' practice works. That, or the architecture manual needs
    changing to mention this other way to avoid wrongful probing by non-PNP isa
    drivers when called by ACPI or isa0.

    If you still want me to try a test I'm game, let me know. It would
    encourage me to do so with the insight provided by some comments on the
    above though.

    Harry

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Scott Long: "Re: location of bioq lock"

    Relevant Pages

    • RE: Odd ACPI behavior
      ... > errors trying to probe the BIOS disabled sio1. ... > under apm and happens twicewhen booting with ACPI and happens even ... Do you kldload a module at some point during your boot? ...
      (freebsd-current)
    • Re: No more floppy drive
      ... The acpi probe automatically falls back to the hints ... The pccard attachment knows there must be a fd. ...
      (freebsd-current)
    • Re: No more floppy drive
      ... The acpi probe automatically falls back to the hints ... The acpi commits did not remove any rtc probe; ...
      (freebsd-current)
    • Re: No more floppy drive
      ... >>why people are seeing their drives disappear now). ... The acpi commits did not remove any rtc probe; ...
      (freebsd-current)
    • Re: Where did debug.acpi.disabled go?
      ... > just doesn't make my floppy to probe and attach correctly anymore. ... > I've attached devinfo -r output for acpi disabled, ...
      (freebsd-current)