All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vandrovec <vandrove-hnqZr3NxcozrBKCeMvbIDA@public.gmane.org>
To: Adam Belay <ambx1-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org>
Cc: Dane Mutters <dmutters-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: (1) ACPI messes up Parallel support in kernels >2.6.9
Date: Thu, 05 Jan 2006 20:20:02 +0100	[thread overview]
Message-ID: <43BD7162.2090906@vc.cvut.cz> (raw)
In-Reply-To: <20060105085559.GA1357-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org>

Adam Belay wrote:
> On Wed, Jan 04, 2006 at 10:52:09PM -0800, Andrew Morton wrote:
> 
>>Dane Mutters <dmutters-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>>	I've been attempting to figure out this problem for a long time, and have 
>>> come to the conclusion that it must be a kernel bug (that or perhaps I'm a 
>>> bit dense).  Whenever I have the option, "Device Drivers > Plug and Play > 
>>> ACPI Support" enabled, I become unable to print using my parallel port.
>>
>>hm, regressions are bad and the fact that it _used_ to work meand that we
>>should be able to make it work again.
>>
>>Could you please raise a bug reports against acpi at bugzilla.kernel.org? 
>>It might help if that report includes the output of `dmesg -s 1000000' for
>>both working and non-working kernels.
>>
>>Thanks.
> 
> 
> This may be a PnP bug.  If you can provide further information, I'll
> look into it.

At least on my hardware (ASUS A8V, W83627THF superio) problem is that it now 
uses ECP...

Once parport_pc is loaded, it says it found PnPBIOS parport and finds printer

parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 
[PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: Printer, HEWLETT-PACKARD DESKJET 690C
lp0: using parport0 (interrupt-driven).
lp0: ECP mode

unfortunately write to /dev/lp* blocks indefinitely.  SuperIO registers 
inspection reveals that SIO is actually programmed to use DMA 1 and not DMA 3. 
When SuperIO is reprogrammed, data are apparently sent somewhere (as writes to 
/dev/lp no longer blocks), IRQ count is incremented for each block sent, but 
unfortunately printer does not seem to agree that any data arrived.

Actually I believe that ECP mode never worked for me - but in the past 
parport_pc just used SPP or EPP, and everything was happy.  Now 'modprobe 
parport_pc io=0x378' does not work anymore as parallel port hardware is kindly 
disabled by PnPBIOS code :-(  So I have to first enable parport in SuperIO, then 
set parport mode to SPP, PS2, EPP1.7 or EPP1.9 (low three bits of F0 register in 
function 1 must be 100, 000, 001 or 101) and load parport_pc io=0x378 
io_hi=0x778 irq=7 dma=1.  Then ECP mode is not used and printing works...

parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
parport0: Printer, HEWLETT-PACKARD DESKJET 690C
lp0: using parport0 (interrupt-driven).

If you are interested, ACPI DSDT is available at 
http://platan.vc.cvut.cz/ftp/private/a8v.acpi.dsdt.  W83627THF datasheet is 
available from Winbond website...  I do not understand AML sufficiently to tell 
whether problem with DMA is caused by parport or AML interpreter or buggy DSDT. 
  Non-working ECP is either dead hardware or parport problem existing for very long.

SuperIO dump after initial parport_pc load:

       RR/EN 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17
BASE: 0B    82 84 FF FE A2 00 00 FF 20 00 00 1A 48 00 00 FF
FN00: 01    03 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 06 FF FF FF 02 FF FF FF
     :       8E 00 FF FF 00 00 FF FF FF FF FF FF FF FF FF FF
FN01: 01    03 78 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 07 FF FF FF 01 FF FF FF
     :       3A FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN02: 01    03 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 04 FF FF FF FF FF FF FF
     :       00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN03: 01    02 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 03 FF FF FF FF FF FF FF
     :       00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN04: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN05: 00    00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF 00 FF 00 FF FF FF FF FF
     :       83 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN06: 00    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN07: 08    02 01 03 30 FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       FF FF FF FF E3 00 FF FF FF FF FF FF FF FF FF 00
FN08: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF 38 00 00 FF 00 00 00 FF FF FF FF FF FF FF FF
FN09: 03    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF 51 00 00 DF 21 00 FF FF FF FF FF FF FF FF FF
FN0A: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       00 AF FF 3F 00 FF 00 00 FF 00 FF FF FF FF 00 00
FN0B: 01    02 90 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PowerState: 01

								Petr

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: Adam Belay <ambx1@neo.rr.com>
Cc: Dane Mutters <dmutters@gmail.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: (1) ACPI messes up Parallel support in kernels >2.6.9
Date: Thu, 05 Jan 2006 20:20:02 +0100	[thread overview]
Message-ID: <43BD7162.2090906@vc.cvut.cz> (raw)
In-Reply-To: <20060105085559.GA1357@neo.rr.com>

Adam Belay wrote:
> On Wed, Jan 04, 2006 at 10:52:09PM -0800, Andrew Morton wrote:
> 
>>Dane Mutters <dmutters@gmail.com> wrote:
>>
>>>	I've been attempting to figure out this problem for a long time, and have 
>>> come to the conclusion that it must be a kernel bug (that or perhaps I'm a 
>>> bit dense).  Whenever I have the option, "Device Drivers > Plug and Play > 
>>> ACPI Support" enabled, I become unable to print using my parallel port.
>>
>>hm, regressions are bad and the fact that it _used_ to work meand that we
>>should be able to make it work again.
>>
>>Could you please raise a bug reports against acpi at bugzilla.kernel.org? 
>>It might help if that report includes the output of `dmesg -s 1000000' for
>>both working and non-working kernels.
>>
>>Thanks.
> 
> 
> This may be a PnP bug.  If you can provide further information, I'll
> look into it.

At least on my hardware (ASUS A8V, W83627THF superio) problem is that it now 
uses ECP...

Once parport_pc is loaded, it says it found PnPBIOS parport and finds printer

parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 
[PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: Printer, HEWLETT-PACKARD DESKJET 690C
lp0: using parport0 (interrupt-driven).
lp0: ECP mode

unfortunately write to /dev/lp* blocks indefinitely.  SuperIO registers 
inspection reveals that SIO is actually programmed to use DMA 1 and not DMA 3. 
When SuperIO is reprogrammed, data are apparently sent somewhere (as writes to 
/dev/lp no longer blocks), IRQ count is incremented for each block sent, but 
unfortunately printer does not seem to agree that any data arrived.

Actually I believe that ECP mode never worked for me - but in the past 
parport_pc just used SPP or EPP, and everything was happy.  Now 'modprobe 
parport_pc io=0x378' does not work anymore as parallel port hardware is kindly 
disabled by PnPBIOS code :-(  So I have to first enable parport in SuperIO, then 
set parport mode to SPP, PS2, EPP1.7 or EPP1.9 (low three bits of F0 register in 
function 1 must be 100, 000, 001 or 101) and load parport_pc io=0x378 
io_hi=0x778 irq=7 dma=1.  Then ECP mode is not used and printing works...

parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
parport0: Printer, HEWLETT-PACKARD DESKJET 690C
lp0: using parport0 (interrupt-driven).

If you are interested, ACPI DSDT is available at 
http://platan.vc.cvut.cz/ftp/private/a8v.acpi.dsdt.  W83627THF datasheet is 
available from Winbond website...  I do not understand AML sufficiently to tell 
whether problem with DMA is caused by parport or AML interpreter or buggy DSDT. 
  Non-working ECP is either dead hardware or parport problem existing for very long.

SuperIO dump after initial parport_pc load:

       RR/EN 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17
BASE: 0B    82 84 FF FE A2 00 00 FF 20 00 00 1A 48 00 00 FF
FN00: 01    03 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 06 FF FF FF 02 FF FF FF
     :       8E 00 FF FF 00 00 FF FF FF FF FF FF FF FF FF FF
FN01: 01    03 78 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 07 FF FF FF 01 FF FF FF
     :       3A FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN02: 01    03 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 04 FF FF FF FF FF FF FF
     :       00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN03: 01    02 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 03 FF FF FF FF FF FF FF
     :       00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN04: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN05: 00    00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF 00 FF 00 FF FF FF FF FF
     :       83 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN06: 00    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FN07: 08    02 01 03 30 FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       FF FF FF FF E3 00 FF FF FF FF FF FF FF FF FF 00
FN08: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF 38 00 00 FF 00 00 00 FF FF FF FF FF FF FF FF
FN09: 03    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
     :       FF 51 00 00 DF 21 00 FF FF FF FF FF FF FF FF FF
FN0A: 01    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       00 AF FF 3F 00 FF 00 00 FF 00 FF FF FF FF 00 00
FN0B: 01    02 90 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF FF FF FF FF FF FF
     :       01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PowerState: 01

								Petr


  parent reply	other threads:[~2006-01-05 19:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-05  6:03 (1) ACPI messes up Parallel support in kernels >2.6.9 Dane Mutters
     [not found] ` <200601042203.12377.dmutters-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2006-01-05  6:52   ` Andrew Morton
2006-01-05  6:52     ` Andrew Morton
     [not found]     ` <20060104225209.56e35802.akpm-3NddpPZAyC0@public.gmane.org>
2006-01-05  8:55       ` Adam Belay
2006-01-05  8:55         ` Adam Belay
     [not found]         ` <20060105085559.GA1357-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org>
2006-01-05 19:20           ` Petr Vandrovec [this message]
2006-01-05 19:20             ` Petr Vandrovec
  -- strict thread matches above, loose matches on Subject: below --
2006-01-05 12:03 Dane Mutters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43BD7162.2090906@vc.cvut.cz \
    --to=vandrove-hnqzr3nxcozrbkcemvbida@public.gmane.org \
    --cc=akpm-3NddpPZAyC0@public.gmane.org \
    --cc=ambx1-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org \
    --cc=dmutters-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.