David Campbell (campbell@torque.net)
Thu, 24 Sep 1998 19:23:39 +0800
Date sent: Thu, 24 Sep 1998 10:35:27 +0200
From: Matthias Welwarsky <matze@stud.fbi.fh-darmstadt.de>
Send reply to: dg2fef@afthd.tu-darmstadt.de
Organization: Fachschaft Informatik der FH Darmstadt
To: campbell@gear.torque.net
Subject: IMM driver weirdness.
> Hi David,
>
> I think the parport handling in your driver is wrong wrt. port sharing.
> Seems that you do the wrong things when there are devices already active
> on a port. If I understood the code you do the following:
>
> 1. register a device on the port (OK)
> 2. claim the port (OK)
> 3. if claim fails, spin in a tight schedule()-loop forever (WRONG)
>
> The offending code is:
>
> --- imm_detect() ---
> /* Claim the bus so it remembers what we do to the control
> * registers. [ CTR and ECP ]
> */
> if (imm_pb_claim(i))
> while (imm_hosts[i].p_busy)
> schedule(); /* We are safe to schedule here */
> --- imm_detect() ---
>From memory what is happening here is a lock out against the SCSI mid-level
driver. In the kernel you can not be sure that some other thread is not running
in the same driver. What has happened in the past is that the driver has just
about finished one task when the next kicks off. Hence p_busy should be
cleared elsewhere...
I am forwarding this to the Linux parallel port list since this starts dealing with
the finer details of parallel port sharing (trust me - I really need to refresh my
knowledge on the subject, it is a bit of a black art at times). If the imm driver
is broken then there is a 95% chance the ppa driver is also broken.
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.
> There are two or three problems:
>
> First: imm_hosts[i].p_busy will never become 0. So once you find a busy
> port, imm_detect() will lock up in the loop. and even if there was some
> code in the driver that resetted p_busy, what about drivers that don't
> ever release a parport they once claimed?
Those drivers should be taken out and shot. The mid-level SCSI driver (which
calls the imm/ppa driver) will panic if the request is not completed in 3
seconds.
> 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.
I am not sure what you are trying to prove here. The 3 second limit imposed
by the mid level SCSI driver has resulted in every other parallel port sharing
device "yielding" when required. The ppa/imm drivers will yield after each
SCSI command in a similar fashion. This is a fundamental issue here with
parport - you are NOT allowed to hog a parallel port or else the whole system
could be brought down.
> 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 */
>
>
> You definitely need to handle signals, otherwise insmod or modprobe will
> block forever.
Voting time, what is everyones (Tim, Phil, Grant, Andrea, anyone else?) ideas
on this subject?
Sorry I haven't got time to seriously think this through myself, I am pulling an
all nighter at the office to get a report off first thing tommorow morning...
(Don't you hate it when reality creeps in on your kernel hacking time?)
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:21 EST