Bug 11603

Created attachment 17914 [details]
ACPI tables dump

Created attachment 17915 [details]
DSDT dump

Created attachment 17916 [details]
dmesg -s999999 with CONFIG_PNP_DEBUG=y

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?

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.

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.

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?

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".

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;
}

> 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.

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

> 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.

If this is still seen on modern kernels then please re-open/update