ACPI PnP on Intel MU440EX

ACPI PnP on Intel MU440EX

[Martin Doucha]

Hi,
I have trouble with ACPI PnP on one of my machines (Intel MU440EX 
motherboard made in '98). ACPI PnP doesn't detect built-in parallel port 
(PNPBIOS does and the port works because I use it to print regularly). I 
know that I can turn ACPI PnP off by editing .config or using 
pnpacpi=off boot parameter. I just want to report this problem before 
PNPBIOS support is dropped (as written in kernel docs).

I have no experience with kernel development or debugging but lots of 
experience with userspace development in C so you can ask whatever 
information you need.

Regards,
Martin Doucha

Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

On Sunday 31 August 2008 07:22:52 am Martin Doucha wrote:
> I have trouble with ACPI PnP on one of my machines (Intel MU440EX 
> motherboard made in '98). ACPI PnP doesn't detect built-in parallel port 
> (PNPBIOS does and the port works because I use it to print regularly). I 
> know that I can turn ACPI PnP off by editing .config or using 
> pnpacpi=off boot parameter. I just want to report this problem before 
> PNPBIOS support is dropped (as written in kernel docs).

Thanks very much for the report.  This sounds like it could be a
PNPACPI issue, which I am very interested in fixing.

Can you please turn on CONFIG_PNP_DEBUG in your .config and collect
the complete dmesg log with and without "pnpacpi=off"?

I do have an "lspnp" that works with PNPACPI here:
  http://kernel.org/pub/linux/kernel/people/helgaas/pnputils-0.1.tar.bz2
but it's not widely used.  The debug information from the config
option above is usually more useful.

Bjorn

Re: ACPI PnP on Intel MU440EX

[Martin Doucha]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Bjorn Helgaas wrote:
> Thanks very much for the report.  This sounds like it could be a
> PNPACPI issue, which I am very interested in fixing.
>
> Can you please turn on CONFIG_PNP_DEBUG in your .config and collect
> the complete dmesg log with and without "pnpacpi=off"?
>
> I do have an "lspnp" that works with PNPACPI here:
>   http://kernel.org/pub/linux/kernel/people/helgaas/pnputils-0.1.tar.bz2
> but it's not widely used.  The debug information from the config
> option above is usually more useful.
>
> Bjorn

I'm sorry it took me so long, here's the output of lspnp -vvv from both 
PNPBIOS and ACPI PnP (same kernel, the only difference is pnpacpi=off 
boot argument). I can't find any mention of my parallel port in ACPI PnP 
output but it's the last listed device (00:15 PNP0400) in PNPBIOS output.

Regards,
Martin Doucha

[-- Attachment #2: pnpacpi.out --]
[-- Type: text/plain, Size: 2695 bytes --]

00:00 PNP0a03 (unknown)
    state = active
    allocated resources:
	io 0xcf8-0xcff

00:01 PNP0303 (unknown)
    state = active
    allocated resources:
	io 0x60-0x60
	io 0x64-0x64
	irq 1

00:02 PNP0f13 (unknown)
    state = active
    allocated resources:
	irq 12

00:03 PNP0201 (unknown)
    state = active
    allocated resources:
	io 0x0-0xf
	io 0x80-0x91
	io 0x94-0x9f
	io 0xc0-0xdf
	io 0x40b-0x40b
	io 0x410-0x43f
	io 0x481-0x483
	io 0x487-0x487
	io 0x489-0x489
	io 0x4d6-0x4d6
	dma 4

00:04 PNP0b00 (unknown)
    state = active
    allocated resources:
	io 0x70-0x71
	irq 8

00:05 PNP0c04 (unknown)
    state = active
    allocated resources:
	io 0xf0-0xff
	irq 13

00:06 PNP0800 (unknown)
    state = active
    allocated resources:
	io 0x61-0x61

00:07 PNP0c02 (unknown)
    state = active
    allocated resources:
	io 0x7000-0x700f
	io 0x8000-0x803f

00:08 PNP0700 (unknown)
    state = active
    allocated resources:
	io 0x3f0-0x3f5
	io 0x3f7-0x3f7
	irq 6
	dma 2
    possible resources:
	Dependent: 01 - Priority preferred
	   port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
	   port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
	   irq 6 High-Edge
	   dma 2 8-bit compatible

00:09 PNP0501 (unknown)
    state = active
    allocated resources:
	io 0x3f8-0x3ff
	irq 4
    possible resources:
	Dependent: 01 - Priority preferred
	   port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 02 - Priority preferred
	   port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 03 - Priority preferred
	   port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 04 - Priority preferred
	   port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 05 - Priority functional
	   port 0x100-0x3f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 1,3,4,5,6,7,8,10,11,12,13,14,15 High-Edge

00:0a PNP8294 (unknown)
    state = disabled
    possible resources:
	Dependent: 01 - Priority preferred
	   port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 02 - Priority preferred
	   port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 03 - Priority preferred
	   port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 04 - Priority preferred
	   port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 05 - Priority functional
	   port 0x100-0x3f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 1,3,4,5,6,7,8,10,11,12,13,14,15 High-Edge


[-- Attachment #3: pnpbios.out --]
[-- Type: text/plain, Size: 3966 bytes --]

00:00 PNP0c02 (unknown)
    state = active
    allocated resources:
	io 0x370-0x371
	io 0xea-0xeb
	mem 0xfffc0000-0xffffffff

00:01 PNP0c01 (unknown)
    state = active
    allocated resources:
	mem 0x0-0x9ffff
	mem 0xe4000-0xfffff
	mem 0x100000-0x5ffffff
	mem 0xfff80000-0xfffbffff

00:02 PNP0200 (unknown)
    state = active
    allocated resources:
	io 0x0-0xf
	io 0x81-0x8f
	io 0xc0-0xdf
	dma 4

00:03 PNP0000 (unknown)
    state = active
    allocated resources:
	io 0x20-0x21
	io 0xa0-0xa1
	irq 2

00:04 PNP0100 (unknown)
    state = active
    allocated resources:
	io 0x40-0x43
	irq 0

00:05 PNP0b00 (unknown)
    state = active
    allocated resources:
	io 0x70-0x71
	irq 8

00:06 PNP0303 (unknown)
    state = active
    allocated resources:
	io 0x60-0x60
	io 0x64-0x64
	irq 1

00:07 PNP0c04 (unknown)
    state = active
    allocated resources:
	io 0xf0-0xff
	irq 13

00:08 PNP0800 (unknown)
    state = active
    allocated resources:
	io 0x61-0x61

00:09 PNP0a03 (unknown)
    state = active
    allocated resources:
	io 0xcf8-0xcff

00:0a PNP0c02 (unknown)
    state = active
    allocated resources:
	io 0x4d0-0x4d1
	io 0x8000-0x803f
	io 0x7000-0x700f

00:0b PNP0c02 (unknown)
    state = active
    allocated resources:
	mem 0xe0000-0xe3fff

00:0c PNP0c02 (unknown)
    state = disabled

00:0d PNP0f13 (unknown)
    state = active
    allocated resources:
	irq 12
    possible resources:
	irq 12 High-Edge

00:0e PNP0501 (unknown)
    state = active
    allocated resources:
	io 0x3f8-0x3ff
	irq 4
    possible resources:
	Dependent: 01 - Priority acceptable
	   port 0x3f8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 02 - Priority acceptable
	   port 0x2f8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 03 - Priority acceptable
	   port 0x3e8-0x3e8, align 0x7, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 04 - Priority acceptable
	   port 0x2e8-0x2e8, align 0x7, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 05 - Priority acceptable
	   port 0x3f8-0x3f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 06 - Priority acceptable
	   port 0x2f8-0x2f8, align 0x7, size 0x8, 16-bit address decoding
	   irq 4 High-Edge
	Dependent: 07 - Priority acceptable
	   port 0x3e8-0x3e8, align 0x7, size 0x8, 16-bit address decoding
	   irq 3 High-Edge
	Dependent: 08 - Priority acceptable
	   port 0x2e8-0x2e8, align 0x7, size 0x8, 16-bit address decoding
	   irq 4 High-Edge

00:11 PNP0700 (unknown)
    state = active
    allocated resources:
	io 0x3f0-0x3f5
	io 0x3f7-0x3f7
	irq 6
	dma 2
    possible resources:
	Dependent: 01 - Priority acceptable
	   port 0x3f0-0x3f0, align 0x7, size 0x6, 16-bit address decoding
	   port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
	   irq 6 High-Edge
	   dma 2 8-bit compatible
	Dependent: 02 - Priority acceptable
	   port 0x370-0x370, align 0x7, size 0x6, 16-bit address decoding
	   port 0x377-0x377, align 0x0, size 0x1, 16-bit address decoding
	   irq 6 High-Edge
	   dma 2 8-bit compatible

00:15 PNP0400 (unknown)
    state = active
    allocated resources:
	io 0x378-0x37f
	irq 7
    possible resources:
	Dependent: 01 - Priority acceptable
	   port 0x378-0x378, align 0x7, size 0x8, 16-bit address decoding
	   irq 7 High-Edge
	Dependent: 02 - Priority acceptable
	   port 0x278-0x278, align 0x7, size 0x8, 16-bit address decoding
	   irq 5 High-Edge
	Dependent: 03 - Priority acceptable
	   port 0x228-0x228, align 0x7, size 0x8, 16-bit address decoding
	   irq 7 High-Edge
	Dependent: 04 - Priority acceptable
	   port 0x378-0x378, align 0x7, size 0x8, 16-bit address decoding
	   irq 5 High-Edge
	Dependent: 05 - Priority acceptable
	   port 0x278-0x278, align 0x7, size 0x8, 16-bit address decoding
	   irq 7 High-Edge
	Dependent: 06 - Priority acceptable
	   port 0x228-0x228, align 0x7, size 0x8, 16-bit address decoding
	   irq 5 High-Edge

Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

On Sunday 14 September 2008 01:28:16 pm Martin Doucha wrote:
> Bjorn Helgaas wrote:
> > Thanks very much for the report.  This sounds like it could be a
> > PNPACPI issue, which I am very interested in fixing.
> >
> > Can you please turn on CONFIG_PNP_DEBUG in your .config and collect
> > the complete dmesg log with and without "pnpacpi=off"?
> >
> > I do have an "lspnp" that works with PNPACPI here:
> >   http://kernel.org/pub/linux/kernel/people/helgaas/pnputils-0.1.tar.bz2
> > but it's not widely used.  The debug information from the config
> > option above is usually more useful.
> >
> > Bjorn
> 
> I'm sorry it took me so long, here's the output of lspnp -vvv from both 
> PNPBIOS and ACPI PnP (same kernel, the only difference is pnpacpi=off 
> boot argument). I can't find any mention of my parallel port in ACPI PnP 
> output but it's the last listed device (00:15 PNP0400) in PNPBIOS output.

I don't see the parallel port either.  Can you please open a
bugzilla for this and attach the complete dmesg log and the
ACPI table dump using the instructions here:

  http://kernel.org/pub/linux/kernel/people/helgaas/debug

You can put it in the Drivers/PNP category and add me to the cc:
list.

I assume the parallel port has *never* worked with ACPI enabled,
right?

Bjorn

[Bug 11603] Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

http://bugzilla.kernel.org/show_bug.cgi?id=11603

Thanks for opening this bug report, Martin.

The DSDT definitely includes the parallel device.  The device can be
in several modes, so there are actually three sections for it: LPT,
EPP, and ECP.  None of them showed up in the PNP debug output, so the
_STA methods must be telling us the device isn't present at all.

If you turn on CONFIG_ACPI_DEBUG and boot with these options:
  acpi.debug_layer=0x10000 acpi.debug_level=0x10

we should see the results of evaluating _STA.

Does the BIOS setup screen have any config items related to the
parallel port?  If so, can you experiment with them and find out
whether they make any difference?

Re: [Bug 11603] Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

Your logs are perfect, which makes me happy because it's the first
time I've successfully used the byzantine ACPI debug infrastructure.

> Log with parport set to auto/bidirectional in BIOS for comparison. PNPBIOS does
> detect it in this setting, ACPI doesn't. Same with auto/EPP which I used until
> now.

I think this is a BIOS defect.

When you set the port to "enabled" in the BIOS, Linux finds and uses
the parallel port with no problem.

When you set the port to "auto/bidirectional" or "auto/EPP" in the BIOS,
the _STA methods on all the parallel devices return 0:

     bus-0117 [00] bus_get_status        : Device [LPT] status [00000000]
     bus-0117 [00] bus_get_status        : Device [EPP] status [00000000]
     bus-0117 [00] bus_get_status        : Device [ECP] status [00000000]

A zero _STA means the device is not present at all, so I think Linux
is right to ignore the devices.

I suppose we could try to add a quirk to Linux to work around this,
but I'm not sure whether it's worth it.  Your machine is from 1998,
and some distros blacklist ACPI on old machines because it's not
worth the trouble to fix all of them.

Some drivers will blindly probe for hardware if PNP doesn't report
anything.  Is parport one of them, i.e., if you load it by hand, does
it work?

Re: [Bug 11603] Re: ACPI PnP on Intel MU440EX

[matthieu castet]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

Bjorn Helgaas wrote:
> Your logs are perfect, which makes me happy because it's the first
> time I've successfully used the byzantine ACPI debug infrastructure.
> 
>> Log with parport set to auto/bidirectional in BIOS for comparison. PNPBIOS does
>> detect it in this setting, ACPI doesn't. Same with auto/EPP which I used until
>> now.
> 
> I think this is a BIOS defect.
> 
> When you set the port to "enabled" in the BIOS, Linux finds and uses
> the parallel port with no problem.
> 
> When you set the port to "auto/bidirectional" or "auto/EPP" in the BIOS,
> the _STA methods on all the parallel devices return 0:
> 
>      bus-0117 [00] bus_get_status        : Device [LPT] status [00000000]
>      bus-0117 [00] bus_get_status        : Device [EPP] status [00000000]
>      bus-0117 [00] bus_get_status        : Device [ECP] status [00000000]
> 
> A zero _STA means the device is not present at all, so I think Linux
> is right to ignore the devices.
> 
If you want you could try to run the attached program on your pc in 
"auto/bidirectional" or "auto/EPP" mode.

This program does what _STA methods do.


Matthieu

[-- Attachment #2: lpc.c --]
[-- Type: text/x-csrc, Size: 612 bytes --]

#include <sys/io.h>

#define S707 0x0370
#define INDX S707
#define DATA S707+1


int R707(int Arg0)
{
	int ret;
	outb(0x55,INDX);
	outb(0x55,INDX);
	outb(Arg0,INDX);
	ret = inb(DATA);
	outb(0xAA,INDX);
	return ret;
}
void W707(int Arg0, int Arg1)
{
	outb(0x55,INDX);
	outb(0x55,INDX);
	outb(Arg0,INDX);
	outb(Arg1, DATA);
	outb(0xAA,INDX);
}



int GSTA()
{
	int ret;
	W707 (0x07, 0x03);
	ret = R707 (0xF0);
	printf("raw %d\n", ret);
	printf("LPT %d\n", (ret & 0x7) == 0);
	printf("EPP %d\n", (ret & 0x3) == 1);
	printf("ECP %d\n", (ret & 0x2) == 2);
	return ret;
}

int main()
{
	iopl(3);
	GSTA();
	return 0;
}

Re: [Bug 11603] Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

> If you want you could try to run the attached program on your pc in 
> "auto/bidirectional" or "auto/EPP" mode.
> 
> This program does what _STA methods do.

I'm just curious -- what do you hope to learn from this program?
Do you think it will tell us more than what actually running _STA
did?

The best solution I can think of would be to have a parameter like
"parport.nopnp" that made parport just probe the legacy addresses,
and document that you might need that on machines with broken ACPI
firmware.  But I'm a little afraid to touch parport_pc.c.

Re: [Bug 11603] Re: ACPI PnP on Intel MU440EX

[matthieu castet]

Bjorn Helgaas wrote:
>> If you want you could try to run the attached program on your pc in 
>> "auto/bidirectional" or "auto/EPP" mode.
>>
>> This program does what _STA methods do.
> 
> I'm just curious -- what do you hope to learn from this program?
> Do you think it will tell us more than what actually running _STA
> did?
> 
Yes I was curious of the value before the mask : some of the mask and 
comparaison look strange.

> The best solution I can think of would be to have a parameter like
> "parport.nopnp" that made parport just probe the legacy addresses,
> and document that you might need that on machines with broken ACPI
> firmware.  But I'm a little afraid to touch parport_pc.c.
Aren't parport still probing it's own port if pnp failed ?


Matthieu

Re: [Bug 11603] Re: ACPI PnP on Intel MU440EX

[Bjorn Helgaas]

> Aren't parport still probing it's own port if pnp failed ?

Could be; I haven't looked.  I just assumed parport didn't do the
legacy probe because Martin reported that the port didn't work when
PNPACPI was enabled.

And I retract my "parport.nopnp" idea.  A positive statement like
"parport.legacy" or something along the lines of "look here" would
be better.  It's safe to use PNP to probe; it just won't find anything.
All we want is something to tell parport to do the legacy probe in
addition.