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