Matthias Welwarsky (matze@stud.fbi.fh-darmstadt.de)
Fri, 25 Sep 1998 12:11:56 +0200
David Campbell wrote:
> *snip* . o O ( Flame war coming on here... )
Oops, sorry. I didn't mean to be offensive, so, if my posting actually
caused anger, I apoligize for that.
> > > 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?
Hm, no. Actually it's one of the amateur radio modem drivers using the
parallel port for wireless communication. The problem is that this
device ist just a big FIFO buffer with no on board intelligence. The
data is exchanged as a raw bytestream and all processing is done in
software. The adapter just feeds a constant stream of bytes into the
computer, so no way to release the port even for a short moment.
Wouldn't make sense either, cause this adapter cannot share the port
with any other device due to the hardware design.
> 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"
Hm, yeah, but if it's the first device to be registered, there is no
need to ask anybody to free the port. It just comes in, takes the bus
and doesn't release it ever.
> 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.
>
mhm? Reading the code it seems that imm_pb_claim() calls parport_claim()
and if the port cannot be claimed p_busy is set to one and it returns 1
to the caller. imm_detect() then spins around p_busy, calling schedule()
in a tight loop until p_busy is cleared. But parport_claim() will fail
on any driver having claimed the port before. So, if this driver never
calls imm_wakeup(), imm_detect() will stay in the loop forever.
> 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.
Ouch. But well, if this is the given policy..
> > 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.
So, if I interpret your lines correctly, devices that don't support
sharing shouldn't use parport? That'd be somehow sad, because the
parport programming interface is quite nice to handle, much nicer than
pure (poor?) in()/out(). Especially the probing for EPP/ECP is a really
nice thing to have ;-)
[...] (code deleted)
>
> 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.
Hm. From my understanding of OS design, shouldn't schedule() only be
called from within a process context (i.e. with a valid "current")? So,
wouldn't the schedule()-loop be wrong anyway if the driver is compiled
into the kernel? calling schedule() without a valid current, there is
the possibility to put the idle task to sleep, which should never
happen. On boot, there might even be no active process at all ;-)
Gruss,
Matthias
-- 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:23 EST