Opened 12 years ago

Last modified 11 years ago

#546 new defect

PCI-e Parallel Port doesn't work in standard setup

Reported by: dbongo Owned by: David Azarewicz
Priority: minor Milestone: Release 4.00
Component: ACPI PSD Version: 3.20.01
Keywords: Cc:

Description

I have a motherboard without a Parallel Port so I installed a PCI-e Parallel Adapter. I installed eCS 2.1 without ACPI and it was recognized and seemed to work fine. I then installed ACPI 3.20.01 and the port disappeared. I have since activated the /VW switch and it's back.

As the system seems to be working fine with the /VW switch I almost classified this as "trivial" priority, but it struck me as odd that a device that does not use an IRQ is having this problem, so I bumped it up to minor. I'll let the experts decide from here.

Change History (10)

comment:1 Changed 12 years ago by David Azarewicz

Milestone: eCS 2.xFeedback pending

Since you didn't say, I assume you are using the PRINT01.SYS driver. This driver will not work if the device is assigned an interrupt higher than 15. Almost all PCI devices are assigned interrupts higher than 15 in the default mode (mode 2) of the PSD. Since you didn't provide any information in the way of logs or PCI output, I assume that your adapter got assigned an interrupt higher than 15. This would be normal and in this case the result is as expected. The adapter will not work in mode 2 because the driver doesn't support interrupts greater than 15. This is not a PSD defect. It is a limitation of the PRINT01.SYS driver. In the absence of an updated PRINT01.SYS driver that supports higher interrupt numbers, using the /VW switch is the correct solution.

If you are not using the PRINT01.SYS driver, please let me know. Or if you would like to provide a testlog or a pci output when booted in mode 2 (without the /VW switch) so I can confirm the interrupt assignment, I would be happy to look at it. Otherwise, I am confident that the problem is as described and is a problem with the PRINT01.SYS driver and not with the PSD.

comment:2 Changed 12 years ago by dbongo

Yes, you are correct it is print01.sys. I'm fairly certain that it did have an IRQ of 16. Which is why I tried the /VW switch. However, it shows no IRQ in the Hardware Manager, so I was scratching my head a bit on that one and thought it worth reporting.

There is another oddity. Printing something essentially freezes the computer. It's not really noticeable on a text print job, but something with graphics can take a minute, which is a long time to sit and stare. All of the CPUs show massive (>90%) load and the PC is unresponsive. Once the document prints, everything is back to normal. It's a hassle, and making me considering trying a USB-to-Parallel adapter. I've not seen this problem before under any version of OS/2 or eCS. I'll check it out without ACPI installed when I get a chance.

comment:3 Changed 12 years ago by David Azarewicz

ACPI has nothing to do with it. You are describing normal operation for the PRINT01.SYS driver when operating in polled mode. If you use the /IRQ switch "BASEDEV=PRINT01.SYS /IRQ" then it won't suck up so much cpu time polling the port when printing.

comment:4 Changed 12 years ago by dbongo

I printed something out on an install without ACPI installed. During printing it was a bit sluggish in that the mouse pointer skipped across the screen. Otherwise the system was normally responsive (i.e. the pointer moved at the correct rate of speed and programs opened as they should). On my ACPI install (with the /VW switch) the system is virtually frozen during printing. You are the expert, you know how ACPI and Print01.sys work, so I'll believe you when you say ACPI has nothing to do with it. But something isn't right here, and ACPI is the difference as far as I can tell.

And I tried adding the /IRQ switch as you suggested. I have an IRQ of 10 assigned, and no sluggishness on the PC end of things. But the first attempt to print a document failed, and the second attempt is still polling after 5 minutes or so. So that fixed the sluggish system response, but seems to have disabled printing altogether.

comment:5 Changed 12 years ago by David Azarewicz

Is your system an Intel system and do you have hyperthreading enabled?

comment:6 Changed 12 years ago by dbongo

Yes. It's got a Core i7 2600 on a Gigabyte Z68X-UD3H-B3 motherboard. And yes on the hyperthreading. I have checked the motherboard manual and gone through the BIOS settings and I have not seen how to disable it. Are there any other terms the BIOS is likely to use for hyperthreading?

comment:7 Changed 12 years ago by David Azarewicz

I suspected that because the symptoms you were describing are typical of hyperthreading problems.

You have to hunt for it but the hyperthreading setting is usually hidden away under "advanced" or similar and/or under CPU options, or similar. It should be a simple enable/disable switch.

comment:8 Changed 12 years ago by dbongo

OK, I did find it. It's buried with the overclocking options. I have disabled it, and things are better, but still not "right" as I would define it. I reverted back to NOT using the /IRQ option as that completely disabled printing. (With the /IRQ option enabled I was unable to print two "normal" pages [i.e. with graphics] so tried to print a test page that said "this is a test" and all I got was some horizontal lines.) There is a very noticeable slowdown while printing, a much greater slowdown than running without ACPI, but the system is not crippled like it was before.

comment:9 Changed 12 years ago by dbongo

I have tried this out on a second multi-core PC. This is an AMD Athlon II X3 455 based system (Asrock 880GM-LE FX motherboard) which has an onboard parallel port. Printing (Laserjet 5L) works fine without ACPI installed, no slowdown whatsoever. (I suspected the "skipping" mouse pointer I noticed without ACPI on the Core i7 was due to Panorama. The AMD system is running accelerated SNAP. I'm not sure if it means anything, but I thought it was worth mentioning.) Anyway, I installed ACPI and printed the same exact PDF file. The system was noticeably slower while feeding data to the printer.

No /VW switch was necessary. (This MB also has a floppy connector, so I'm guessing that it and the parallel port are on some sort of legacy ISA bus?)

ACPI was the only change to the system configuration between tests. I'm not sure how valuable (if at all) this information is, and I do realize that I may be one of the last people running parallel ports for printing, but something seems amiss to me.

comment:10 Changed 11 years ago by David Azarewicz

Milestone: Feedback pendingRelease 4.00
Note: See TracTickets for help on using tickets.