Brian T. Schellenberger (bts@babble.on.home)
Tue, 03 Aug 1999 13:24:27 -0400
grant@torque.net wrote:
>
> > First of all, my posts lately have all been met with thunderous silence.
>
> That's probably because there's only one of me and I don't always have the
> time to respond during the week.
I guess that I was hoping that somebody else could jump in . . .
It is quite a burden if you must carry it by yourself.
> > Have I offended y'all? Broken some rule of which I was unaware? If
> > so, my apolgoies.
>
> Well, you could turn off the HTML in your postings - it makes them even
> more formidable than they already are.
*oops!* Sorry, done.
> I'll try to deal with some of your recent mails ...
>
> > Ok, I have made some progress. I can get away from the "device busy"
> > (general probe failure, really) messages if I turn *OFF* EPP mode.
> > Either ECP or SPP or "non-extended" mode seems to work for probing
> > the device. Using non-extended mode I can successfully burn small
> > disks.
>
> Well, that seems to suggest that there is something odd about the EPP
> port on your laptop. I don't know anything about Hyperbooks -
It's not a very big manufacturor, though I've been happy with mine.
Back when bought it (almost three years ago now) they offered Linux
as one of the O/Ss you could buy pre-installed, though they've since
dropped it, but still when it was still under manufacturor's warrenty,
they wouldn't freak when you explained that you were running Linux and
such-and-such happened.
> do you
> know what sort of parallel port chip it uses ? Try getting the
> "testport" utility from www.micro-solutions.com and running it under DOS.
> It might identify your port.
Thanks for the pointer. It says (and I quote):
LPT= 0378, C0 00 FF 00 00
Bidirectional
Chipset: SMC FDC37C665IR
Mode: EPP
> > insmod pg drive0=0x378,0,0,1,-1,0
>
> > but it seems to be slower than with the delay of 1! Moreover, it still
> > seems to be lots slower even when I default it like I was doing before.
> > So I'm really lost.
>
> Are you getting I/O errors with the delay at 1 ? I can't otherwise
> imagine how it could be "slower".
I think that this was probably coincidence. Further testing seems to
show that the port is simply very inconsistent. Every once a blue moon,
it will come up in the right state and paride will actually see that it
can open it in EPP mode (mode 5), though even then it's too slow for me
to write an entire disc while building an ISO file system in another
process (on my P-166 system) with X running but not active.
Even when it's running in SPP (or "non-extended") mode, where it is
consistently recognized, at least, it will not provide consistent
performance from iteration to iteration, and since the tests take a long
time to run, it's hard to use the trick of averaging runs for more
consistent data.
Still, the Windows code seems to manage some magic to reset it to a
sensible state and thus get consistent results there. This suggests
that one possible approach would be to boot under windows and then
soft-reboot under Linux. Unfortuantely, after what was an apparent
virus incident I've made that impossible; I have Linux and Windows on
seperate disks and I physically swap out the disk to change operating
systems, which requires me to power down. (The HyperBook has a modular
design, so apart from powering down and up, swapping HDs is a 10-second
operation.)
However, I could try booting from floppy or even making a small DOS
partition if you think that's worthwhile.
> > Ok, I've played around even furhter, and determined that EPP mode does
> > seem, in fact, to work, as long as I can get pg to ignore the fact that
> > it says it doesn't. Under Windows, the "Shuttle" program recognizes
> > that it's in EPP
>
> Quite probably the Shuttle driver knows something about your parallel port
> and how to adapt for its peculiarities.
>
> > If I burn a disk I get a couple errors [they say
> > "D0100 error (05/64/00) Command error - illegal mode for this track",
>
> Or more likely, the Shuttle driver is adjusting some timing to adapt
> for errors it detects, but from this it would seem that there driver is
> not entirely successful, either.
>
> > *So* what I really want to do is create my own hacked version of the pg
> > driver that is hard-coded to know whatever it needs to know about the
> > HP-7500 and ignore error codes from the parallel port since it is a
> > known liar.
>
> That's utter stupidity. If the tests fail, its because my driver is
> not able to talk to your adapter in that mode. This isn't something
> like overclocking a CPU, its a matter of changing the actual on-the-wire
> protocol that the driver uses to transfer information. For whatever
> reason, the protocol is not working with your port.
Thank you for expressing yourself. I can verify, however, that you are
quite correct in saying that this approach won't work at all. I've
tried
it, and, to make a long story short, as I skip over each sanity check
the
next one fails and eventually we start trying to set up the device with
no information in hand about how it's supposed to work.
> > Also, how do I know if my EPP is 8-, 16-, or 32-bit? When I use
> > SPP mode, I'm simply informed that it connected in mode 1 (3/5), which
> > I guess means that it's either 8- or 32-bit, but how can I tell which?
> > I can't use mode 1 if I'm hacking "pg" to not be allowed to ask the
> > device which one works . . .
>
> The way you know if you port is capable of EPP-8, 16 or 32 is to do a
> data transfer and see if you get the right thing. Of course, you have
> to use the EPP protocol to do that.
Owing to the single success I've had (not reproducable of course), I now
know that mode 5 works when it's in a good mood.
> What you've told us so far is that NONE of the protocols work when your
> port is set into EPP mode, and only modes 0 and 1 work if you set it
> to SPP mode. As far as writing goes, modes 0, 1 and 2 are all the same.
> They differ in the way data is _read_ from the device. Mode 0 uses
> (at least) 2 i/o cycles for every 4 bits. Mode 1 uses 3 i/o cycles for
> every 8 bits by reading 5 bits from one port and 3 from another (hence
> the 3/5 designation) and mode 2 uses two i/o cycles for every 8 bits
> (so called "bidirectional" or "PS/2" mode).
>
> > 2. How can I make just the parport modules? When I try this, I get:
> >
> > [paride]# make
> > Makefile:174: /Rules.make: No such file or directory
> > make: *** No rule to make target `/Rules.make'. Stop.
> >
> > I can go up to the kernel root and "make modules" from there, but then
> > it re-compiles *everything* (which seems to obviate the whole purpose of make,
> > but that's another story). This makes using printk for debugger *very*
> > tiresome. How can I get it to compile only the paride pieces?
>
> Try upgrading to a current kernel - there were bugs in the makefiles
> (both PARIDE's makefile, and in the handling of MODVERSIONS, in 2.0).
I'd prefer to not risk purterbing the parts of the system that work
and, frankly, the RedHat 5.2 directions for upgrading the kernel to 2.2
scared me off . . .
-- Brian T. Schellenberger, "Brian, the man from babble-on" babbleon@bigfoot.com-=: It don't mean a thing if it ain't got that swing :=-
-- To unsubscribe, send mail to: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Tue 03 Aug 1999 - 18:05:14 EDT