I have had this problem since 0.9, and it has only partially been fixed in 1.0
(I haven't tried 1.0-current yet)

In 0.9, I had to go into the kernel source and modify the bit masks for the
"Walking Ones" and "Walking Zeros" tests that the probe routine did on the
data and status registers.  For some reason it was expecting to be able to
modify one of the bits that (I thought) should be read-only (ie. tied to
a status line on the printer)

I fixed the mask, and then it would probe the port, but only when the printer
was actually turned on during the probe sequence.  (And, when it is probed,
the printer goes nuts, probably because the walking-zeros/ones pattern is
telling it do do some strange stuff...)

In 1.0, I did not have to modify the mask, but the device still won't
probe unless the printer is turned on.  I suspect that the probe routine 
is trying too hard to see if the stuff at 0x378 is really a printer port.

Chalk it up to the bogus PC adapter card design of the ISA bus, which is 
more like plug-and-fiddle than plug-and-play.  When there is no better way
to detect the presence of the printer port than to frob the status bits
and look at them afterward, well, what do you expect?

Once I get more hard drive space, fixing this niggling little thing is at the
top of my priority list.  I like leaving my printer off until I need to print,
and it's a pain remembering to turn the printer on at boot time...

Does that help?
Tom

(Hmmm. or maybe not, now I've got a serial Postscript printer, so I don't
care as much...  But if you have kernel source maybe you could look at it...)