Brian T. Schellenberger (email@example.com)
Sat, 17 Jul 1999 00:14:52 -0400
First, Grant, thank you for taking the time to help me out.
I'm sure that you have other things to do besides help each
new person to get paride stuff working and I really appreciate
the time that you put into that (and into the paride project as
> > I'm having troubles with device-busy messages . . .
> I wish the developers of modutils would do something about that message.
> It means only that the driver being loaded was unsuccessful at
> initialising itself. It's a single bit status - so the apparently
> specific message from insmod is just silly.
Yeah, by the time I actually sent this message I'd finally worked that
out, but I sure wasted a lot of time thinking that the device or file had
been locked or something of that ilk just because the message sounds
so sure of itself. Something like "unable to initialize device" would be
a lot more helpful.
> > Moreover, I just acquired an HP
> > 7500 CD-Writer and I'm running into the same difficulty.
> I've already sent you some pointers to known problems with the 7500.
Thank you. If I can get pg to initalize again, that'll probably be just
what I need; alas, I've only gotten that to happen once.
> > Paride and epat insmod just fine.
> Loading them doesn't actually _do_ anything. They are really just
> support libraries.
I suspected as much but was trying to be complete. Thanks for the
> > % insmod pg verbose=on
> verbose takes a number :-) No clue what insmod does with "on" in that
(*oops*.) I knew that once FWIW, verbose=2 and verbose=on seem to
produce the same results.
> > [> > [bts@babble bts]$ dmesg
> > Memory: sized by int13 088h
> > Console: 16 point font, 400 scans
> Please try to trim the dmesg stuff down to just the relevant messages.
> (But yes, I know that relevance isn't always obvious.)
The theory was that there might be some OS build version numbers
or something else buried in there someplace . . . I suppose that it was
pretty obvious that the console font wasn't terribly relavent, though.
> > pg: pg version 1.02s, major 97
> > pg0: epat: port 0x378, mode 0, ccr 0, test=(255,255,510)
> > pg0: epat: port 0x378, mode 1, ccr 40, test=(255,255,510)
> It appears that there might be an epat at 0x378, but it seems to be
> unhappy. My guess is that a previous failed operation has left the
> drive in a peculiar state.
The only prior thing I'd done with it was to try to insmod pg once
before and have it fail, but next time I will be sure to set verbose to
2 before I do anything else.
> I also notice that your parallel port is set to either SPP or ECP mode.
> Try setting it to EPP mode if you can. It is also possible that the
> port itself is in an odd state. You may need to power cycle the computer
> as well.
Thats odd because I *did* power off the computer and go into the BIOS
and set the port to "SPP / EPP" mode. Alas, there is no "EPP only"
mode. Is there some standard way to be sure of the mode and/or to
set it? A pointer the right faq info would be highly cool.
(I tried grepping for EPP in both the FAQs and HOWTOs but didn't
> When that happens sometimes you must not only power off the drive,
> but also disconnect it from the parallel port. There's enough power
> on the port to keep the EPAT alive.
I'll try disconnecting and powering off everything and doing a verbose=2
as soon as I reboot next time.
Thanks again, Mr. Guenther, and if anybody else has thoughts and
suggestions I certainly welcome them.
Again, the "device busy" message happens for both the 7500 (pg) *and*
the Sparq (pd), so something more fundamental than just the 7500 bug
is going on . . .
-- Brian T. Schellenberger, "Brian, the man from babble-on" firstname.lastname@example.org
Things can't be too bad in a world with swing music, can they?
This archive was generated by hypermail 2.0b3 on Sat 17 Jul 1999 - 00:02:04 EDT