David Campbell (campbell@torque.net)
Fri, 25 Sep 1998 07:16:02 +0800
Date sent: Thu, 24 Sep 1998 17:28:31 +0200
From: Matthias Welwarsky <matze@stud.fbi.fh-darmstadt.de>
*snip* . o O ( Flame war coming on here... )
> > I have yet to hear of a report detailing a lock-up when "insmod ppa" or
> > "insmod imm" which is atributable to the circumstances that you are suggesting.
>
> I can assure you of that. I accidetially tried the ppa-driver before,
> and it locked up the same way. Just forgot to mention this in my
> previous mail, I'm sorry.
What other device cause the lock out? the lp driver?
> I have a network adapter on
> the first parport that will exactly to that: claim the port on open(),
> release it on stop(). So you need to have to implement a counter that
> makes you give up after some attempts or, even better, don't wait for
> the bus to become idle at all but unregister the driver again and try
> the next port.
Urk! Sounds like this driver needs to be made a lurker. There is support for
a device class where it claims the parallel port whenever no-one else is using
it. From memory this was for the PLIP driver. The lurker device has an extra
call back to say:
"please free the parport when possible, someone else wants the parport"
At this stage the lurker should at the first convient time free the parport
(even if it has more work to do), as soon as the device has finished with the
parport, the lurker collects the parport. For a network device this would be
between sending/recieving packets.
The limitations of lurking is that only one device can be a lurker,
therefore you can not have a Xircom style parallel port network adapter and
PLIP at the same time (this would be plain silly).
Now that I think I know what the problem is, which exact device driver is it?
It looks like some parport code fixes might need to be done.
> Hmno. There are cases where a driver just cannot release the port. You
> seem to assume that parport is really a bus like scsi with per command
> adressing, blockwise transfers aso. But this is only true for a certain
> class of devices, like ZIPs and e.g. scanners. Actually there are
> devices that cannot be addressed/deaddressed or
> disconnected/reconnected.
*nod*
Now comes the explanation about the p_busy bit (slowly it comes back).
a) imm_pb_claim() will always succeed except when some other kernel
thread is running inside the imm driver. The first thing that
imm_pb_claim() does is check the p_busy "spin lock" to prevent the
driver clobbering itself.
b) imm_pb_claim() calls parport_claim(), should parport_claim() fail then
a line of code puts the imm driver to sleep until the parport driver
frees the parport and does a call back to wake the driver.
> If a driver is required to allow "stealing" of its ressources, parport
> is simply fundamentally broken. As long as the device is actually in use
> by the driver, how should it release it's ressources? If it would, and
> another driver would try to initialise its native hardware on that port
> (which will fail), it'll propably leave the attached device broken. Now,
> what happens when the original driver comes back - bang.
Read the above comments on lurking parport drivers.
> For your own driver you may be able to guarantee the 3 seconds maximum
> preemption delay, but not for others.
*shake head in horror*
Even with perfect premption the ZIP driver at one stage clobbered the
kernel by continuous IO. Seriously a telnet half way around the world
was faster at times that using another virtual console.
> So,if the kernel stability actually demands on this,
> I'd regard this as a fundamental design flaw.
Where did I put Alan Cox's email on the EXT2FS and dodgy drivers.
Sometimes a low level driver (like ppa/imm) may return "driver error"
which in turn causes the ext2fs filesystem to panic. Alan's attitude
on this matter was "fix the problem with the driver - not ext2fs".
Basically I am going to take the same line here.
> Actually, there should be a method to find out if a device supports
> scsi-style disconnect/reconnect and in the NO case *not* to wait for the
> bus to be released but just skip the port and try your luck at the next
> one. There just HAS TO BE a method to say "this port is mine, don't try
> to muck with it." If parport does not support this, it's broken. Look,
> for the sharing to work properly, *every* driver must use the parport
> interface, even those that actually don't support sharing.
Parport does support legacy devices, there is nothing from stoping
you coding a driver which totally ignores parport sharing and claim the
IO port address like a SCSI or network card. Parport should then quietly
note this and remove the parport from the list available. If this is not
happening then I think some coding changes need to be done.
> Don't misunderstand me here: Your handling of the parport is correct if
> your assumptions about the attached devices are correct. But within
> imm_detect() you cannot be sure of the bus topology, thats why it's
> broken.
Huh?? parport was once called parbus, that is why there is imm_pb_claim()
Phil & Tim, I think I need a little help explaining the parport concept here...
> > > Second, if you really think you should wait for the bus to become idle:
> > > The wait loop is *very* unfriendly to other processes. It should be like
> > > this:
> > >
> > > while (port_busy) {
> > > current->timeout = jiffies + timeout;
> > > current->state = TASK_INTERRUPTIBLE;
> > > schedule();
> > > if (signals_pending(current)) {
> > > /* someone hit ^C to interrupt us */
> > > goto out;
> > > }
> > > }
> > >
> > > ...
> > > out:
> > > /* clean up and exit */
With daylight and a couple of doses of cafinee here are my thoughts:
a) This will only fix modules, should the two drivers be compiled in the
kernel then all hell will break loose.
b) I am prepared to stick this code in but it will cause a large debug
kernel message dump listing EVERYTHING remotely attached
to the parallel port. When I recieve the listing I will start a
crusade to fix the buggy driver.
Yes I agree the documentation for parport probably needs some work
done.
David Campbell
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers
d) Boot proms for parport devices (socket onto NE2000 cards)
Any assistance to clearing this list most welcome
-- 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 Wed 30 Dec 1998 - 10:18:22 EST