Bug 180390

You made a urgent blocker bug but you didn't provide information
which give us at least a chance to reproduce it.
You even didn't mention your printer model.
And your hardware architecture is set to "Other" - what is it?

I don't have SLED 10 RC2 running on my workstation.
Parallel port printing worked and works well for me all the time
using Suse Linux 10.1 and there is no difference in the packages
of the printing system between Suse Linux 10.1 and SLED 10.
Therefore I could simply close it as WORKSFORME.

Please provide useful information which give us a chance
to find out what goes wrong on your machine.

Perhaps it is somehow a duplicate of bug #172056?
Go carefully through all the stuff in bug #172056 and check
if something is the same for you.

Everything in bug #172056 is the same for me except this is on SLED 10 RC2 i586.

I had to manually create /etc/sysconfig/hardware/hwcfg-static-printer
after this the lp module loads, but the printer still is not configurable via yast2. 'echo -en "\rhello\r\f" > /dev/lp0' works.

When I go to 'yast2 > hardware > printer > add > directly connected printers > parallel printer' a message is displayed the states: "No parallel devices (/dev/lp?) found. It seems that your parallel port is not properly configured." with an OK button.

I have tried this with two different printers: Epson Stylus Color 740 & Brother MFC-P2000.

I have tried this on two different machines, with their parallel ports set to SPP or Output Only: HP ML310 G2 server & HP dc5100MT Mini Tower Desktop.

Should I re-open bug #172056??

It seems there is a difference:

In bug #172056 there was no "lp" module loaded even after
/etc/sysconfig/hardware/hwcfg-static-printer was created.
When there is no "lp" module loaded, "echo ... >/dev/lp0"
doesn't print anything (but you won't get an error - the
command simply wouldn't do anything).

In your case the "lp" module is loaded and "echo ... >/dev/lp0"
works for you (i.e. I assume it really prints "hello").

Again we have two problems:

A)
Why is /etc/sysconfig/hardware/hwcfg-static-printer not cerated
for SLED (this happens both for you and in bug #172056)?
I cannot reproduce it and I have no idea how to debug this
(see my comments in bug #172056).
Perhaps it helps to provide all YaST log files which may show
a problem during installation? Best simply attach /var/log/YaST2/*
as gzipped tar archive to this bug, see
http://en.opensuse.org/Bug_Reporting_FAQ#YaST
Perhaps it is best to make a new bug report regarding only this
problem to get the different problems seperated.

B)
Why does YaST report "No parallel devices found" when the "lp"
module is loaded and when "echo ... >/dev/lp0" prints?
To debug this, please provide the current YaST log file as follows:
1. Move the old one away:
   mv /var/log/YaST2/y2log /var/log/YaST2/y2log.save
2. Run the YaST printer config until the error message appears.
3. Copy the current log file:
   cp /var/log/YaST2/y2log /tmp/y2log.bug180390
4. Attach /tmp/y2log.bug180390 as "text/plain" attachment to this bug.

Regarding comment #4 problem A):
How exactly did you install the system?
Pure YaST or something like zen-installer, rug, smart, ... ?

When testing with
  echo -en "\rHello\r\f" >/dev/lp0
the printer must support direct printing of ASCII characters
(otherwise it won't print "Hello" and eject the sheet.)
I know that the Epson Stylus Color 740 supports it.
I don't know for sure that the Brother MFC-P2000 supports it
but according to
http://www.brother-usa.com/discontinued/printer/mfcp2000/mfcp2000_spe.html
"Compatibility: PCL4 / Epson FX-850 / IBM Proprinter XL"
it should support direct printing of ASCII characters.

I can test this first thing tomorrow morning in the office when
I do my next install (as I still have your printer Johannes).

Regarding problem A)
  I will attach the y2logs.
  I installed via a pure yast2 install.
  Yes, 'echo -en "\rHello\r\f" > /dev/lp0' prints Hello on the upper left of a sheet of paper with the Epson Stylus Color 740. I no longer have the Brother printer, but I can get it if needed. I included that as a data point to eliminate the printer as the point of failure.

Regarding problem B)
  I have also attached the plain text log that specifically deals with the printer configuration.

Created attachment 87859 [details]
zipped YaST2 logs showing installation and printer add failure

Created attachment 87860 [details]
YaST2 log of failed printer add

Jiri, Michal,
could you please inspect the YaST logs
(Jiri in particular the logs in comment #10
and Michal in particular the log in comment #11).
See comment #4 what it is all about.

In particular the log in comment #11 seems to show severe problems:
-----------------------------------------------------------------------
Printer.ycp:1040 Parsing file '/var/lib/YaST2/printers' failed
Printer.ycp:1040 SCR::Read() failed
-----------------------------------------------------------------------
Again it looks like a broken system or at least like a broken YaST,
similar like
https://bugzilla.novell.com/show_bug.cgi?id=172056#c17

As it looks like a somehow broken YaST, I change the component to YaST
(at the moment I don't know better - of course it can be something else).

David, can you attach also '/var/lib/YaST2/printers' file?
And what is your yast2-printer version? rpm -q yast2-printer

I see also:
Printer.ycp:294 Probed printers: []
This is parsed output from hwinfo
David, put here also output from "hwinfo --printer"

If you think it's hwinfo, attach the log of 'hwinfo --printer --log=xxx'.

In response to Comment#14: the /var/lib/YaST2/printers file is an empty (zero byte) file.

The YaST2 printer version is: yast2-printer-2.13.16-1.2

In response to Comment#15: nothing is returned when "hwinfo --printer" is issued from a terminal window.

In response to Comment#17: the logfile is attached. It looks like all of hwinfo was incorporated in this attached file.

Created attachment 88059 [details]
Output of the command: "hwinfo --printer --log=hwinfo-printer-output.txt"

kernel says

  <6>parport: PnPBIOS parport detected.
  <6>parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
  <6>parport0: Printer, EPSON Stylus COLOR 740
  <6>lp0: using parport0 (interrupt-driven).

and later

  <6>parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
  <6>parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
  <6>parport 0x378: You gave this address, but there is probably no parallel port there!
  <6>parport0: PC-style at 0x378 [PCSPP,TRISTATE]
  <6>pnp: Device 00:07 activated.
  <6>parport: PnPBIOS parport detected.
  <6>pnp: Device 00:07 disabled.
  <6>lp: driver loaded but no devices found

So detection works the first time but not later (after reloading the parport
modules).

I don't think that's a blocker, though, as it works for Johannes and so seems
not to be a general problem.

For me this also works fine (both x86_64, i386). 
This seems to be some kernel bug, yes?
Who is responsible for this? Or can I assigne to you, Steffen?
Would /var/log/messages helps you? 

I agree this is not general problem, decrease serverity to Major (Major loss of function)

No, I see nothing I can do here. Maybe the kernel does not like reloading
the parport module in this case - but unfortunately there's no way around
it as the kernel provides no other means to trigger parport device detection.

Regarding comment #20 "it works for Johannes":
To avoid misunderstandings: I only tested with Suse Linux 10.1 (on x86_64).
I didn't test SLED10 but this bug and bug #172056 seems to indicate
that there is a general problem with SLED10 (not a general problem
with CODE10 but probably a general problem with SLED10).
Therefore there is the question which difference between Suse Linux 10.1
and SLED10 lets this problem happen?

Regarding parport stuff does no longer work after reloading the parport
modules, have a look at bug #116655 starting at
https://bugzilla.novell.com/show_bug.cgi?id=116655#c52
and regarding the error message "You gave this address, but there
is probably no parallel port there!", see
https://bugzilla.novell.com/show_bug.cgi?id=155474#c6
and
https://bugzilla.novell.com/show_bug.cgi?id=173782#c33

Summary:
Meanwhile I think there is really something fishy with the parport code
in the kernel therefore I added the parport kernel guru to CC.

Vojtech,
can you have a look what is going on here?

David,
can you experiment with various parport settings in your BIOS
if there is one setting which works well for you?

Reassigning to kernel-maintainers (because of comment#20 - IMHO reloading of kernel module couldn't provide any problems like this)

Steffen, can you give me the complete 'dmesg' with the points where the modules
get removed/inserted celarly marked? Also remote access to a machine whether
the 'second detection doesn't work' problem can be reproduced would help.

I don't have a machine with this bug. I just looked at the kernel
messages logged in comment 19.

David, could you provide that info?

In response to Comment#24: it seems that some settings work better than others. The possibilities on the mode setting in the BIOS are:
Output-only
Bi-directional
EPP+ECP

The possibilities on the Port, Interrupt, DMA settings are:
Disable
378-37F
278-27F
3BC-3BE
378-37F IRQ7
278-27F IRQ7
3BC-3BE IRQ7
378-37F IRQ7 DMA 1
278-27F IRQ7 DMA 1
3BC-3BE IRQ7 DMA 1
378-37F IRQ7 DMA 3
278-27F IRQ7 DMA 3
3BC-3BE IRQ7 DMA 3

The DMA setting doesn't persist unless EPP+ECP mode is selected. Otherwise, it drops the DMA seting and retains the Port and Interrupt setting.

In testing out the various BIOS settings, once the system is rebooted with any setting (except disable), it will function with the command: echo -en "\rHello\r\f" > /dev/lp0

However, if I go into Yast2 > Hardware > Printer it appears to detect the printer initially, if the BIOS settings are:
([378-37F || 278-27F || 3BC-3BE] IRQ 7 [DMA 1 || DMA 3]) && mode=EPP+ECP
or
([378-37F || 278-27F || 3BC-3BE] <No Interrupt>) && mode=Output only

At this point, it appears that once the intial detection is accomplished everything seems to save properly with the click of the "Finish" button. However, with the mode=EPP+ECP settings mentioned above, attempting to print with: echo -en "\rHello\r\f" > /dev/lp0
is no longer working and going back into Yast2 > Hardware > Printer > Edit > Test > <Any test case> causes an error saying that the CUPS server could not communicate with the device. At this point, printing is not possible. The behavior appears to be the same with the mode=EPP+ECP settings if the printing modules (lp, parport_pc, parport) are unloaded with rmmod and reloaded with modprobe.

However, with the polling && Output only settings printing appears to funtion properly with YaST2 > Hardware > Printer > Finish and going back into YaST2 > Hardware > Printer > Edit > Test > <Any Test Case>. Additionally, echo -en "\rHello\r\f" > /dev/lp0 functions after the printer setup in Yast and the unloading then loading of printer modules.

It appears with all the other port, interrupt settings that immediately after reboot the command:  echo -en "\rHello\r\f" > /dev/lp0
works. But, if Yast is employed in setting up the printer, nothing is detected or functional (i.e., no devices are seen through the parallel port). After Yast setup is attempted or after the unloading and loading of the printer modules, the command: echo -en "\rHello\r\f" > /dev/lp0
no longer functions.

I have made this machine available for troubleshooting. The IP address is: 151.155.192.54 within the Novell production network.

Thanks for the very detailed description! It helped me a lot to understand the
problem. 

This looks exactly like bug #116655, however the fix for that bug is already included in the SLES10 RC2 kernel. So most likely it's yet another problem with the ACPIPnP code. 

This snippet from dmesg looks very wrong:

  parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
  parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
  parport 0x378: You gave this address, but there is probably no parallel port there!
  parport0: PC-style at 0x378 [PCSPP,TRISTATE]

A probe was done for the port ...

  pnp: Device 00:07 activated.

but only AFTER that the device got enabled by ACPIPnP, which is why the probe must have failed.

  parport: PnPBIOS parport detected.
  pnp: Device 00:07 disabled.

Then the parport is disabled again ...

  lp: driver loaded but no devices found

And we try to detect a printer through the disabled port, failing again.

To find the real cause of the problem, I'll need root access to the machine and the ability to reboot it. What is the root password?

Sorry, I should have thought to include it in the previous comment. Root password is: novell

Thanks, I'll take a look. Can you please install the kernel sources matching the
installed kernel and kernel development tools on the machine? The only configured installation source currently seems to be the CD, which is not inserted.

This being a SLED 10 RC2 install, I haven't put the sources/kernel dev tools on this platform before. How do I go about doing this? With the SLES 10 CDs? SDK? Doing a search?

The tools seem to be installed - "yast -i kernel-source" should do the trick of installing the kernel sources.
And when you're done - can you leave the SLED9RC2 CD/DVD in? Just in case I need more packages ...

OK, it will be done copying soon. I will leave CD4 in the drive. Thanks.

*** Bug 185135 has been marked as a duplicate of this bug. ***

It is a bug in PnPACPI and possibly the ACPI BIOS, too. Again. It's not enabling the parallel port i/o resources properly, and thus once they're disabled by unloading the parport module (the disabling works just fine), the parallel port is never enabled correctly again.

I've found at least three bugs in that code, fixed two, worked around the third by hardcoding some values, but still it's not enough - I couldn't make it work. I believe some help from the Intel ACPI folks will be needed.

Vojtech,
many thanks for your efforts!

Is there a better workaround except to try out various BIOS settings
until a working set is found (see also bug #185135)?

E.g. a kernel parameter regarding ACPI (or something else)
or whatever special parport options in /etc/modprobe.conf
which they can set to force a working parport mode?

Using 'pnpacpi=off' on the kernel command line should do the trick.

Johannes: The kernel supports all and any of the BIOS parport combinations. The less featured ones are more likely to work in problematic setups, of course, but may be significantly lower performance.

Are there unexpected side effects when 'pnpacpi=off' is used?

According to
/usr/src/linux-2.6.16.20-0.12/drivers/pnp/pnpacpi/Kconfig
-------------------------------------------------------------
Linux uses the PNPACPI to autodetect built-in
mainboard resources (e.g. parallel port resources).
...
Also the PNPACPI can help prevent resource conflicts
between mainboard devices and other bus devices.
-------------------------------------------------------------
For which other mainboard resources (except parport) is PnPACPI used?
Which resource conflicts should be expected if 'pnpacpi=off' is used?

Perhaps this are silly questions but I didn't find documentation
about PnPACPI neither in kernel-source nor in kernel-docs RPMs
except Documentation/kernel-parameters.txt and the above which
are not really explanatory ;-)

Linux can probe for most legacy devices (parallel ports, serial ports, keyboard controller) without the help of PnP. For Windows, there is PnPACPI. So it usually doesn't hurt to disable it in Linux, while enabling is considered a 'cleaner' way to detect the devices - the machine tells us where they are and port probing is not necessary. When it works.

So: I don't expect any adverse effects when disabling it. BUT with ACPI one never knows and some ACPI BIOSes may rely on some of the io-port ranges to get reserved by PnPACPI.

*** Bug 185135 has been marked as a duplicate of this bug. ***

*** Bug 198661 has been marked as a duplicate of this bug. ***

*** Bug 185135 has been marked as a duplicate of this bug. ***

Ok, there seem to exist dozens of duplicates for this one... I wonder why not that much people are in CC? Maybe I'll go through duplicates and add some people to CC to get faster response.

David: The machine is not reachable in the network anymore. It would be great if you could add it again.

Maybe some people could attach dmesg and acpidump output (best in separated unzipped attachements, that's easiest to access...).

Adjusting product to SP1 (and priority, pls don't fiddle with this, severity is important, I don't care about priority), even for this one we have to hurry up to get things included...

ping

I can get another system on the network for you that exhibits the behavior. Which OS would you prefer?

SLE[SD] 10 SP1.
As so much machines seem to be affected I set this to critical now, with some luck we still might get this in if it's found soon and the patch is not too intrusive...

Off topic:
A negative side effect (It happened to me also several times...) is that if bugs of an OpenSUSE product are marked as duplicate for an Enterprise product, all the reporters and people in CC are stripped off the list of CC'ed people...

So we lost all 10.1 and 10.2 reporters of these bugs:
Bug 228795 Bug 258790 Bug 185135 Bug 196670 Bug 201917 Bug 206380 Bug 187713 Bug 198661
I wonder how we could improve this with still having enough security and people who shouldn't see a bug, don't see it. IMO reporters should always get into CC of a duplicated bug. Varda do you want a seperate bug against bugzilla for this?

I add the reporters to CC now, after spending a lot time in reporting and debugging they should not get cut off and not even see how and when this got fixed. Beside we might get help here and things would have moved on more quickly. Maybe someone already came a bit further and knows whether this already got addressed mainline or in an other distribution?

On topic:
Can everybody attach acpidump please and state whether you also see a similar message like this:
  parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
  parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
  parport 0x378: You gave this address, but there is probably no parallel port
there!
(Best in one comment when attaching acpidump so that things stay toghether, we may have several problems here, I want to avoid confusion..).

(In reply to comment #50)
> A negative side effect (It happened to me also several times...) is that if
> bugs of an OpenSUSE product are marked as duplicate for an Enterprise product,
> all the reporters and people in CC are stripped off the list of CC'ed people...
>
> So we lost all 10.1 and 10.2 reporters of these bugs:
>  Bug 228795  Bug 258790  Bug 185135  Bug 196670  Bug 201917  Bug 206380  Bug 187713
> Bug 198661
> I wonder how we could improve this with still having enough security and people
> who shouldn't see a bug, don't see it. IMO reporters should always get into CC
> of a duplicated bug. Varda do you want a seperate bug against bugzilla for
> this?

When you say Varda do you mean Vance Baarda? I'll assume yes.

Here's the message you see when you dup a public bug to a private one:

======================================================================
Duplicate Warning

When marking a bug as a duplicate, the reporter of the duplicate is normally added to the CC list of the original. The permissions on bug 242391 (the original) are currently set such that the reporter would not normally be able to see it.

Adding the reporter to the CC list of bug 242391 will immediately allow him/her access to view this bug. Do you wish to do this?

Yes, add the reporter to CC list on bug 242391

No, do not add the reporter to CC list on bug 242391

Throw away my changes, and revisit bug 254799
======================================================================

Therefore, the person who dup's one bug to another is responsible for deciding whether the reporter should be on the CC list of the private bug.

For info on the other issue, see these bugs:

https://bugzilla.novell.com/show_bug.cgi?id=240443
https://bugzilla.mozilla.org/show_bug.cgi?id=108983

I have a machine on the Novell backbone that you can look at:
IP=137.65.241.180 (DHCP)
gateway=137.65.243.254
Machine name=hp-dc7700

It has SLES SP1 RC1 installed on it and a printer hanging off it; I verified that it is exhibiting the behavior noted above.

Let me know if you need anything else.

Not certain if my old bug (in OpenSUSE 10.1) is really the same, but it could be.

I ran 3 different acpidumps, one with the recommended "Output-only" configuration per the previous workaround to my bug, one set as ELP+EPP, and one while trying to print, all three were identical. None of the lines listed were found in the dump, were they supposed to be there or in some other log file? (When I did switch the BIOS config, Yast2 did not report any problem with the printer config - but it would not print until I switched back to Output-only.)

Still need the acpidump?

People are currently looking at this again.
It seems the bug is still valid for current kernels.

Unfortunately information is clustered over several bugs.

It would be nice if:
  - people seeing this, not able to install a recent 10.2 or 10.3 and testing
    latest kernel could post their machine model, so we can possibly reproduce
    this

or even better:
David, can you still offer a login to the affected machine?

Bjorn: all interesting info for you should be Vojtechs comment #42. I expect one of his fixes is git commit: ccc4c7bbd6a2d47bf5899c2c8cf2e0d176a4dc0f, but as he said it was not enough... As soon as I can reproduce this or access an affected machine, I can help here.

pnpacpi=off boot parameter was reported to solve/workaround this issue.
Any reports/help to finally fix this are welcome...

I can put a machine out on the network that exhibits the issue. Which installed OS would you prefer?

A recent 10.3 Alpha snapshot would be perfect. Thanks!

I installed OpenSUSE 10.3 Alpha7 on the box at 151.155.192.3 gateway is 151.155.195.254. It is exhibiting the issue as seen in /var/log/messages dated around Aug 9 at 12:42pm.

This is the ACPI ASL code of the printer device.
How it gets parsed by pnpacpi I cannot say yet... I try to get out some more...

Device (LPT0)
        {
            Name (_HID, EisaId ("PNP0400"))
            Name (_DDN, "LPT1")
            Name (CRES, ResourceTemplate ()
            {
                IRQNoFlags ()
                    {7}
                IO (Decode16,
                    0x0378,             // Range Minimum
                    0x0378,             // Range Maximum
                    0x00,               // Alignment
                    0x03,               // Length
                    )
            })
            Method (_STA, 0, NotSerialized)
            {
                If (LPTN (LETR ()))
                {
                    Store (0x03, LDN)
                    Store (CFG1, Local0)
                    And (Local0, 0x07, Local0)
                    If (LEqual (Local0, Zero))
                    {
                        If (ACTR)
                        {
                            LEXT ()
                            Return (0x0F)
                        }
                        Else
                        {
                            LEXT ()
                            Return (0x0D)
                        }
                    }

                    If (LEqual (Local0, 0x04))
                    {
                        If (ACTR)
                        {
                            LEXT ()
                            Return (0x0F)
                        }
                        Else
                        {
                            LEXT ()
                            Return (0x0D)
                        }
                    }
                    Else
                    {
                        LEXT ()
                        Return (Zero)
                    }
                }
                Else
                {
                    Return (Zero)
                }
            }

            Method (_CRS, 0, NotSerialized)
            {
                CreateWordField (CRES, 0x01, IRQW)
                CreateByteField (CRES, 0x05, IOLO)
                CreateByteField (CRES, 0x06, IOHI)
                CreateByteField (CRES, 0x07, IORL)
                CreateByteField (CRES, 0x08, IORH)
                LETR ()
                Store (0x03, LDN)
                Store (IOAL, IOLO)
                Store (IOAH, IOHI)
                Store (IOAL, IORL)
                Store (IOAH, IORH)
                If (LEqual (INTR, Zero))
                {
                    Store (Zero, IRQW)
                }
                Else
                {
                    Store (One, Local0)
                    ShiftLeft (Local0, INTR, IRQW)
                }

                LEXT ()
                Return (CRES)
            }
        }
    }

This is how the printer's resources get parsed by pnpacpi
pnp: ACPI device : hid PNP0401
pnp: Resource table dump:
pnp: Port 0: start: 0x378 - end: 0x37f - flags: 257
pnp: Port 1: start: 0x778 - end: 0x77d - flags: 257
pnp: Irq 0: 0x7 - flags: 1025
pnp: dma 0: 0x1 - flags: 2048
I had a short look at the ACPI spec about resource parsing, but have no time to evaluate this further now. On a first look, I'd say DMA should not be used here. The variables used:
 CreateWordField (CRES, 0x01, IRQW)
 CreateByteField (CRES, 0x05, IOLO)
 CreateByteField (CRES, 0x06, IOHI)
 CreateByteField (CRES, 0x07, IORL)
 CreateByteField (CRES, 0x08, IORH)

all point to IO or IRQ resources, but pnpacpi or even the ACPI interpreter itself seem to find a DMA info in this Resource Template.
I will add acpidump. It should be possible to debug this with acpiexec in userspace (acpiexec DSDT.dat -> increase debug level on resources and then execute the _CRS function should give a pointer).

I can go on here in about three weeks after holidays...

Len, the Intel website is still pointing to a rather old acpica version, it would be nice to work on a more recent one:
http://developer.intel.com/technology/iapc/acpi/downloads/acpica-unix-20061109.tar.gz

Created attachment 159178 [details]
acpidump of an affected machine

All the important info is in the SSDT not the DSDT!

Moving to 10.3, hopefully the bug is publically available then.
I hope to be able to spend some time on this the next days...

I still cannot set it public myself... adding David, he commented recently on the kernel.org sibling bug: http://bugzilla.kernel.org/show_bug.cgi?id=5832

David: If you look at comment #63 and comment #64, this looks like a PNPACPI or ACPI resource bug.
The device is working fine without DMA (proved by using PNPBIOS), but when using PNPACPI DMA is enabled, even there are only IO ports and an IRQ defined in _CRS (See comment #63)

OK, how can I best help? Make sure the machine is available over the network? Run some debug code?

Great that there are still some people interested in this one.

Thanks to Li, he pointed me to another ACPI device, that also serves the parallel port.

What I think is going on here:
Often you can configure in BIOS whether ECP/EPP mode for parallel port should be used.
ACPI is too dump to only export one device, therefore it exports two and the OS must check for the _STA (status -> present or not where the BIOS settings are evaluated) function whether the device should get used or not:
 Device (ECP0)
 {
            Name (_HID, EisaId ("PNP0401"))
            Name (_DDN, "LPT1")
...

This device makes use of these resources:
IRQ: 7
DMA: 3
IO:  0x378
IO:  0x778

 Device (LPT0)
 {
            Name (_HID, EisaId ("PNP0400"))
            Name (_DDN, "LPT1")
 
This device makes use of these resources:
IRQ: 7
IO:  0x378


IMO either:
 1) the _STA function is not evaluated in PNPACPI layer at all
   (couldn't find it, but not 100% sure)
 2) This is really a BIOS bug and the _STA function is returning wrong values
   (I doubt it as so many machines are affected), or whatever other weirdness

If it's 1., this is a kernel bug that should be easy to solve.

David: If you tell me what would fit best for you and what distribution (SLED/10.3) you are running I can provide you with a debug kernel rpm for verification. 10.3 would be preffered, but I can also come up with a SLED rpm if it's more convenient for you.

You could also have a look at the BIOS settings, maybe there serial/parallel port can be configured? Look out for ECP/EPP parallel port options.
If ECP is enalbed and you switch to EPP it might also already work.
There is still the bug then, that it is luck that ACPI parses the EPP ACPI device first and assigns it to the parport_pc driver.

Thomas,
very many thanks that you care so much about this problem
which hits often also me when printing doesn't work.

Do I understand your comment #69 correctly that the bug happens
when there is the ambiguous "ECP/EPP" setting in the BIOS
instead of either a definite "ECP" or a definite "EPP" setting?

What I guess (it's just a guess for now):
There are 2 ACPI devices (ECP/EPP) serving the parallel port in ACPI.
I expect that currently it is luck which one the parport_pc driver gets assigned to, because the _STA (is the device present? Am I allowed to use it?) is not evaluated by the PNPACPI layer.
I expect it works like that:
If in BIOS ECP is set, the _STA function of the PNP0400 (ECP) device will return present and the other one not and vice versa.
So if you switch this setting in BIOS and it didn't work before, it will now work because it gets the right one of the two devices (which doesn't fix the bug in kernel -> not evaluating _STA, but it could already give a hint and workaround...).

Can someone try this kernel:
ftp.suse.com/pub/people/trenn/pnp_check_for_status_fix_parport
It's a 10.3 i386 kernel with the fix and some extra debug lines included.
If this one works, it's the status function not checked and this is the appropriate fix (without debug message) for that.

Tried the kernel in comment #72; no difference.  EPP works as usual, ECP+EPP or just ECP just give:
lp0: using parport0 (interrupt-driven).
DMA write timed out

and doesn't print.  In my case at least, the bug is not limited to the ECP+EPP dual mode in the BIOS.

There should be some additional info in dmesg, can you post the non-functional one, pls.

Created attachment 182925 [details]
dmesg from boot to (not) print

I don't see any additional output in this, but perhaps I don't know what I'm looking for.

Thanks Henryk.
It seems it's not the not evaluated status.
The additional info is e.g.:
pnp: pnpacpi_add_device: ACPI device: PNP0401 - Status: [0000000f]
(PNP0400 is missing)
If you set your BIOS to EPP mode there should pop up a PNP0400 device instead of PNP0401, that means status evaluation seems to work.

My next idea is:

pnpbios and pnpacpi BIOS information obviously differs.
I expect that those machines are already a bit older and the M$ OS did use pnpbios at that times.
It could be that the vendor found out that DMA does not work on this machine and only disables it in pnpbios tables, resulting that pnpacpi still exports DMA and this is not working...
My next approach ist to fallback to pnpbios on BIOSes older than XY.
I suggested a patch on kernel.bugzilla.org (there it needs to be accepted to get a solution upstream).
As soon as it's accepted upstream, I can add the fix to several versions of our kernels (this should be a rather unrisky thing to do).

It would be great if people could get an account there and attach dmidecode output to this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=5832

This will:
1) Show that a lot people are affected which increases the chance that a fix gets accepted
2) Provides the BIOS dates of affected BIOSes to be able to adjust the blacklist date appropriatly

I do not believe that to be the issue, at least in my case.  Older SuSE kernels (9.x?) worked fine with ECP.  Somewhere around 10.0, it would work with ECP unless the modules were reloaded (which the yast2 printer module apparently does, among other things), at which point it would cease to function until reboot.  Sometime later (not sure when, I had to switch to EPP and there was no progress on the bug) it has apparently stopped working even right after boot if ECP is enabled.  The only other data point I can offer is that NT OSs don't seem to have a problem with ECP (at least not NT 5.0 or 5.1).

Given this, it seems unlikely that DMA simply doesn't work for the port.  Certainly it would be hard to reconcile this with the works-until-reloaded behavior in early 10.x.  Is there a way to reliably tell if DMA is being used in Windows (I know it will sometimes lie about IDE DMA status, so...)?  Alternatively, would it be helpful or possible to directly compare the pnpbios and pnpacpi information?  Generally, before I start lobbying the upstream kernel, is there a way to be sure I'm blaming the right thing?

> I do not believe that to be the issue, at least in my case.  Older SuSE
> kernels (9.x?) worked fine with ECP
But that would exactly explain this. This could be the times when pnpacpi was introduced

> Somewhere around 10.0, it would work with ECP unless the modules were reloaded
This is weird..., maybe diffing the parport_pc module helps, no idea...

I don't know exactly where pnpbios info comes from. It's probably also some parsed tables exported via BIOS.
The same for pnpacpi info. For pnpacpi I can pretty sure say that the parsed info (with dma enabled) is correct (in respect of parsing).

While pnpbios is more mature, I expect it's also parsed correctly (with dma disabled) and the fact that it works makes me think it's the info that should be preferred on these machines.

Can you still provide dmidecode output, pls. I expect this only affects older machines and switching to pnpbios on these shouldn't cause any harm.

>> Somewhere around 10.0, it would work with ECP unless the modules were reloaded
> This is weird..., maybe diffing the parport_pc module helps, no idea...
One of the old bugs in the duplicate chain had someone at SuSE who was sure he knew what the problem was (and that it was in parport).  Unfortunately, this was about 10.0 and I have no idea how to find that information now.  As the bug tumbled into a novell-private bug, I lost interest and just assumed I wouldn't be able to use DMA anytime soon.

One thing that may be relevant: I noticed that the BIOS is set to give the port DMA 3, NT lists it as using DMA 3, but:
parport0: PC-style at 0x378 (0x778), irq 7, dma 7 [PCSPP,TRISTATE,COMPAT,EPP,ECP, DMA]
is printed.  Could this simply be a misallocation of the DMA channel by the kernel?  That would certainly explain the DMA write time outs!  I tried booting with parport=0x378,7,3 but it still printed the above message.  I guess something else is overring the parport command line-I wonder where DMA 7 is coming from?

I will supply the dmidecode info to the kernel.org bug once I am able to create an account there.

That you get DMA channel 7 should come from the fact that pnpacpi provides several channels to OS which it can choose from.

Have you already tried pnpacpi=off boot parameter?
Maybe in your case pnpbios does not switch off the DMA channel totally, but only provides DMA channel 3 and everything is working fine. In this case I strongly recommend to blacklist older machines to use pnpbios by default.

> parport=0x378,7,3
You can try to rmmod parport_pc and try to load it with:
modprobe parport_pc io=0x378 irq=7 dma=3
(modinfo parport_pc)
to get this as default (also at boot time you can add this to /etc/modprobe.conf.local):
options parport_pc io=0x378 irq=7 dma=3

That someone in 10.0 who knew where it broke was me. The problem was that without pnpacpi the parallel port was enabled by the BIOS and stayed so while the kernel was using it.

Unloading the module disabled the device through pnpacpi and unfortunately the enable code was completely wrong in pnpacpi (I hope my patches are in mainline now), and didn't enable the DMA properly.

After trying pnpacpi=off to no avail (still ended up with DMA 7), I got a sinking feeling and decided to check /etc/modprobe*.  In /etc/modprobe.conf.local:
options parport_pc io=0x378 irq=7

Interestingly, commenting this out gives me DMA 3 with or without pnpacpi=off.  I can then print, but only so long as I (or yast, or whatever) don't reload parport.  In other words, it reverts to the behavior I remember from 10.0.

I guess specifying an IO port and an IRQ causes parport not to probe for a DMA.  How it decides that "7" is a good value when none is specified is a mystery to me, but I consider the issue secondary to the module reloading bug.  As the latter is independent of pnpacpi=off, I think you may be right in that it is a parport problem and blacklisting would not be helpful.  This may be a different bug than the one on kernel.org.

There is no additional output when failing to print after reloading the module-no DMA write timed out or anything.

Regarding comment #81, I can only say that I'm still seeing the bug, so your patches must not be in kernel-default-2.6.22.12-0.1.

Puhh...
So we have:
 - pnpacpi and pnpbios may return different resources to use
 - parport_pc works with specific resources passed, but won't after reload
   (in your case, on other systems it is needed)
 - in your case both pnpacpi and pnpbios does not work (the latter does work
   for others)
 - ...

From this I'd say there is definetely something broken in parport_pc.
Don't know whether it can be polished up to be more clever in auto detecting resources.
That it does not work after reload with the same options looks like parport_pc is heavily broken.
Jean has already submitted the one or the other patch for it, maybe he has an idea.

You might want to add the
#define DEBUG{_PARPORT} 1
lines as I stated here:
http://bugzilla.kernel.org/show_bug.cgi?id=5832
to get out some more info from the parport_pc driver.

I don't think I can help here, sorry. The fixes I submitted for the parport_pc driver were really only cosmetic things, I don't know anything about the parport_pc driver internals.

Well, it's not quite that bad.  pnpbios and pnpacpi both provide good information for me provided nothing is specified: to be clear, it was only when I had a parport line in modprobe.conf that specified IRQ and IO but not DMA that I ended up with the wrong DMA.  Offhand, I'd guess that since the result is the same mod pnpacpi and is wrong, parport isn't actually using either in that case.  One could argue this case isn't important since if you know the IO and IRQ to put in modprobe.conf, you probably know the DMA too.  On the other hand, paport's documentation sure doesn't say "specify all three or DMA will be wrong" anywhere. So, probably a bug, and probably surprising if you don't happen to know this, but it can be worked around.

The reloading thing is a little stranger.  I have discovered that if you rmmod parport_pc && modprobe parport_pc && modprobe lp && rccups restart after the module is initially reloaded (by hwinfo, for instance), you can print again!  I'm not sure if that recipe is minimal yet.  Naturally, hwinfo doesn't do any of this, so if you don't happen to know this works, you can't print until you reboot.

I've built the debug kernel, as suggested, and it produces a really impressive amount of output.  I can supply dmesgs for the partially specified modprobe case or for the can't-print-until-rereloaded case, as you like.

Could the parport stuff perhaps be changed that it strictly
uses whatever is specified in modprobe.conf (if there is
something specified) regardless what any kind of autodetection
might result?
This way it would at least be possible to enforce whatever values
instead of the current trial and error approach?

Johannes, comment #82 seems to imply that printing *does* work fine if modprobe.conf doesn't specify any i/o or dma address, and it *fails* when dma 7 is  specified, which seems to be the value after install.

IMO this means that something is writing an invalid value (7 really isn't the right number for ECP DMA, I have yet to see a board that doesn't have ECP on either DMA channel 3, or in a few cases 1) to the configuration file, either during install or even as a part of some package.

Once we remove the manually entered options and let the kernel autodetect, it works, but then still unloading the module kills the parallel port using ACPI PnP, physically disabling it, and the enable-code is still not good enough to bring it to life.

From several user reports (i.e. from all user reports which I got
up to now):
The parport does not work out-of-the-box after system installation
which means it doesn't work if nothing is specified in modprobe.conf
because this are the "parport" lines in my modprobe.conf after
a openSUSE 10.3 default installation:
-------------------------------------------------------------------------
alias parport_lowlevel    parport_pc
# options parport_pc io=0x378 irq=none,none
# options parport_pc io=0x378,0x278  irq=none,none
-------------------------------------------------------------------------

Furthermore comment #82 seems to show that when "irq=7" is
specified it leads to "DMA 7" but "IRQ" != "DMA" so that
according to comment #79: "Could this simply be a misallocation
of the DMA channel by the kernel?"

In any case I don't think it is a good idea to provide manually set
options to the user/admin but later ignore them in the kernel.
Here is seems the kernel tries to apply too much of its own additional
"intelligence" when values are specified in modprobe.conf.

Even if there would be whatever broken printer setup tool which writes
nonsense to modprobe.conf, then this broken tool must be fixed
but as far as I know there is no such tool.

I would even like to have a "mode" option in modprobe.conf
so that in case of trouble the user could enforce all parport
parameters to the kernel e.g.:
options parport_pc io=0x378 irq=7 dma=3 mode=ecp

Yes, I shouldn't write bugzilla comments before I fully wake up. Indeed, DMA and IRQ are very different things, and 7 is a sane value for a printer port IRQ.

To figure out where the wrong DMA number 7 comes from, I'd suggest booting
with parport.verbose_probing=1.

Anyway, when PnP is used, the parport code isn't doing any probing and just blindly uses what PnP passes to it as the DMA channel. Read DMA probing would only happen when PnP is not used.

Yep 7 is definetly wrong and I doubt it's the one that came from pnpacpi.
I have two affected acpidumps here (Henryk, you may also attach acpidump output or point me to if you've already done so).

The one works with _CRS/_PRS/_SRS (Current, Possible, Set) Resource Settings.
While the possible DMA settings are:
{0,1,3}
and another one where it's only working via _CRS and DMA is set fixed to: 3
(but 3 does also not work there :) , may have to do with the double loading, or whatever).

Henryk, for pnp (could be different for pnpbios or pnpacpi, by passing pnpacpi=off boot param) you can check the settings exported and passed to the parport_pc driver by (only in 10.3 AFAIK):
for x in /sys/devices/pnp0/*;do echo "$x"; cat $x/id;done
Watch out for the PNP0401 (ECP) device and do:
cat /sys/devices/pnp0/XY/resources

> I'd suggest booting with parport.verbose_probing=1
Yep, good idea. Or add verbose_probing=1 to the parport_pc driver as module param...

Created attachment 183414 [details]
Another acpidump from an affected machine

OK, some more information.  /sys/devices/pnp0/00:0c/resources reads:
state = active
io 0x378-0x37f
io 0x778-0x77b
irq 7
dma 3

in all cases, which seems to be right.  Booting with parport.verbose_proving=1 just gives:
Unknown boot option `parport.verbose_probing=1': ignoring

so I added it to modprobe.conf.  So long as there's nothing else about parport in modprobe, this gives:
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
Winbond chip at EFER=0x2e key=0x87 devid=52 devrev=17 oldid=ff type=83627
Winbond LPT Config: cr_30=00 60,61=0378 70=07 74=03, f0=3b
Winbond LPT Config: active=no, io=0x0378 irq=7, dma=3
Winbond LPT Config: irqtype=pulsed low, high-Z, ECP fifo threshold=7
Winbond LPT Config: Port mode=ECP and EPP-1.9
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
pnp: Device 00:0c activated.
parport_pc 00:0c: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7<7>0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 9
0x378: readIntrThreshold is 9
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x48
0x378: ECP settings irq=7 dma=<none or set by other means>
, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: Printer, Hewlett-Packard HP LaserJet 6L

With the IO and IRQ specified, but not DMA:
parport0: PC-style at 0x378 (0x778), irq 7<7>0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 9
0x378: readIntrThreshold is 9
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x48
0x378: ECP settings irq=7 dma=<none or set by other means>
, dma 7 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: Printer, Hewlett-Packard HP LaserJet 6L

Offhand, it's interesting that there's nothing about the Winbond chip in the latter case, and also the dma=<none or set by other means> then the dma on the next line is interesting, but it doesn't really say what the "other means" are, or why they're wrong in the latter case.

I also managed to get the following after rmmod'ing and reloading parport, but I can't reproduce it reliably:
parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
parport 0x378: You gave this address, but there is probably no parallel port there!
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]

I am pretty sure now, this has not much to do with pnpacpi or whatever..., the parport_pc driver looks rather broken, e.g.:

#ifdef CONFIG_PARPORT_1284
		p->ops->ecp_write_data = parport_pc_ecp_write_block_pio;
		/* currently broken, but working on it.. (FB) */
		/* p->ops->ecp_read_data = parport_pc_ecp_read_block_pio; */
#endif /* IEEE 1284 support */

Does not sound very promising.

The next bug is the dma=<none or set by other means> output you get.
In ECP case it reads out a config port and prints out the value (in this case none or set by other means, but may also be a true value), but does not use it..., the dma 7 is the used one.

This all is so old ..., I fear we break more than doing any good...
I tend to close this one won't fix...

You need to pass dma=none explicitly, this should avoid the dma 7 channel.

"wontfix" would be really bad.

If the ECP mode cannot be fixed, is it perhaps possible
to let the parport system fall back to the EPP mode
so that it works at least somehow?

Or is it not possible use another mode as fallback in the kernel
than the mode which is defined in the BIOS?

Or could the ECP mode be used only with certain settings
in modprobe.conf (if yes, which exact settings?) so that
we could provide at least some documentation for our users?

I could imagine some sanity checks could be added without much risk (e.g. don't use dma 7).

Johannes, maybe the best is we discuss this in our office together with Torsten Duwe. He has much more experience with serial/parallel devices and said something that dma shouldn't be used at all with "newer" (but still old) parallel ports...

According to Torsten Duwe, we should disable DMA totally.
Some already tried and AFAIK all who had problems here had a working parallel port with dma=none Parameter, right?

Johannes, I am not sure how risky this is and whether it should be done in 10.3, maybe also SLE[SD]10-SP2. Maybe we should start with stable and let some people test first...

The solution should be a line in /etc/modprobe.d/xy:
options parport_pc dma=none
Johannes, AFAIK you already added the comment, if two parallel ports are found, that parport_pc should get irq=none parameter, can you also add the dma=none uncommented, pls.

Some testing whether it still works after reloading parport_pc driver would also be great.

I added never such a comment anywhere.
I don't do anything in the kernel or in kernel-related stuff.

Ahh, I understand, it wasn't you who added these:
-------------------------------------------------------------------------
alias parport_lowlevel    parport_pc
# options parport_pc io=0x378 irq=none,none
# options parport_pc io=0x378,0x278  irq=none,none
-------------------------------------------------------------------------
to /etc/modprobe.conf...

Adding maintainer of module-init-tools.
Michal: I suggest to add:
options parport_pc dma=none
in /etc/modprobe.conf
for 11.0/stable.
I would not touch this for 10.3, people should add this manually if they have problems.
Can you do this, pls and close the bug then.

By the way:

Isn't there a tiny typo in the comment

# options parport_pc io=0x378 irq=none,none

Shouldn't it be just

# options parport_pc io=0x378 irq=none

If yes, could this typo be also fixed?

(In reply to comment #99 from Johannes Meixner)
> Isn't there a tiny typo in the comment
> 
> # options parport_pc io=0x378 irq=none,none

I don't know, maybe.

Fixed package submitted (including the comment change).

Here's my case: the printer works fine without any option passed to parport_pc (parport0: PC-style at 0x378 (0x778), irq 7, dma 3[PCSPP,TRISTATE,COMPAT,ECP,DMA]), until the module is reloaded. After that, any access to /dev/lp0 hangs, regardless of passing dma=none or not (I added the line "options parport_pc dma=none" to /etc/modprobe.conf.local). I got this once: 

Mar 15 16:19:27 linux kernel: pnp: Device 00:09 disabled.
Mar 15 16:19:27 linux kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff
Mar 15 16:19:27 linux kernel: parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff
Mar 15 16:19:27 linux kernel: parport 0x378: You gave this address, but there is probably no parallel port the
Mar 15 16:19:27 linux kernel: parport0: PC-style at 0x378 [PCSPP,TRISTATE]
Mar 15 16:19:27 linux kernel: pnp: Device 00:09 activated.
Mar 15 16:19:27 linux kernel: parport_pc 00:09: reported by Plug and Play ACPI
Mar 15 16:19:27 linux kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA
Mar 15 16:19:27 linux kernel: parport0: Printer, Hewlett-Packard HP LaserJet 1100
Mar 15 16:19:28 linux kernel: lp0: using parport0 (interrupt-driven).

, the other times the syslog messages were normal:

Mar 15 16:57:35 linux kernel: pnp: Device 00:09 activated.
Mar 15 16:57:35 linux kernel: parport_pc 00:09: reported by Plug and Play ACPI
Mar 15 16:57:35 linux kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA
Mar 15 16:57:44 linux kernel: lp0: using parport0 (interrupt-driven).
Mar 15 16:58:33 linux kernel: lp0: ECP mode

The BIOS setting is EPP/ECP mode and Winbond chip at EFER=0x2e key=0x87 devid=87 devrev=08 oldid=00 type=unknown.

This is irritating as both yast and the vmware configuration script seem to reload parport_pc. 

Comment #102 "works fine ... until the module is reloaded"
looks like bug #116655
"parport in ECP mode doesn't work after rmmod & insmod"

FYI regarding "yast ... seem to reload parport_pc":
It isn't YaST itself which reloads parport modules.
It is the hardware detection via hwinfo which is
called by YaST to autodetect parport printers, see
https://bugzilla.novell.com/show_bug.cgi?id=116655#c52