Bug 11603 - PNPACPI parport detection failure on MU440EX motherboard
PNPACPI parport detection failure on MU440EX motherboard
Status: RESOLVED OBSOLETE
Product: Drivers
Classification: Unclassified
Component: PNP
All Linux
: P1 normal
Assigned To: Adam Belay
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-20 11:28 UTC by Martin Doucha
Modified: 2012-10-30 15:10 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.26.2
Tree: Mainline
Regression: No


Attachments
ACPI tables dump (30.40 KB, text/plain)
2008-09-20 11:30 UTC, Martin Doucha
Details
DSDT dump (88.15 KB, text/plain)
2008-09-20 11:31 UTC, Martin Doucha
Details
dmesg -s999999 with CONFIG_PNP_DEBUG=y (15.06 KB, text/plain)
2008-09-20 11:32 UTC, Martin Doucha
Details
dmesg -s999999 with CONFIG_ACPI_DEBUG=y, LPT on/bidi (24.20 KB, text/plain)
2008-09-21 02:31 UTC, Martin Doucha
Details
dmesg -s999999 with CONFIG_ACPI_DEBUG=y, LPT auto/bidi (22.09 KB, text/plain)
2008-09-21 02:42 UTC, Martin Doucha
Details

Description Martin Doucha 2008-09-20 11:28:33 UTC
Earliest failing kernel version: never worked
Distribution: Gentoo
Hardware Environment: Intel Celeron 266MHz, Intel MU440EX motherboard
Software Environment: Phoenix BIOS, GRUB
Problem Description: ACPI PnP doesn't detect on-board parallel port. PNPBIOS does detect it and the port works.

Steps to reproduce: Boot kernel compiled with CONFIG_PNPACPI=y
Comment 1 Martin Doucha 2008-09-20 11:30:37 UTC
Created attachment 17914 [details]
ACPI tables dump
Comment 2 Martin Doucha 2008-09-20 11:31:12 UTC
Created attachment 17915 [details]
DSDT dump
Comment 3 Martin Doucha 2008-09-20 11:32:06 UTC
Created attachment 17916 [details]
dmesg -s999999 with CONFIG_PNP_DEBUG=y
Comment 4 Bjorn Helgaas 2008-09-20 15:59:32 UTC
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?

Comment 5 Martin Doucha 2008-09-21 02:31:28 UTC
Created attachment 17920 [details]
dmesg -s999999 with CONFIG_ACPI_DEBUG=y, LPT on/bidi

ACPI seems to find the port when set to "enabled" in BIOS (I think this didn't work yet when I got it working for the first time with PNPBIOS). I'm not sure this is the log you need from ACPI though.
Comment 6 Martin Doucha 2008-09-21 02:42:33 UTC
Created attachment 17921 [details]
dmesg -s999999 with CONFIG_ACPI_DEBUG=y, LPT auto/bidi

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. The visible difference between auto and enabled is that you don't set specific port/IRQ for auto mode.
Comment 7 Bjorn Helgaas 2008-09-22 16:01:31 UTC
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?

Comment 8 Martin Doucha 2008-09-23 00:57:50 UTC
No, I can get it working now and the last thing kernel needs is more cruft. Just make a note about this in parport documentation and close this report as invalid. I'll stick to "enabled".
Comment 9 CASTET Matthieu 2008-09-23 14:30:17 UTC
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
#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;
}
Comment 10 Bjorn Helgaas 2008-09-24 16:05:25 UTC
> 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.

Comment 11 CASTET Matthieu 2008-09-25 11:52:57 UTC
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

Comment 12 Bjorn Helgaas 2008-09-25 13:11:16 UTC
> 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.

Comment 13 Alan 2012-10-30 15:10:46 UTC
If this is still seen on modern kernels then please re-open/update

Note You need to log in before you can comment on or make changes to this bug.