bunnell@wizard.asel.udel.edu (Tim Bunnell) (01/03/90)
There does seem to be a problem with 1.44 meg floppies in 1.5.0 (or with my hardware or both). After booting (via a 1.2 meg drive), a 1.44 meg floppy will mount correctly on my system, but attempts to read it (e.g. list a directory) will produce garbage. 760k floppies always seem to work fine. Moreover, having one accessed a 760k floppy in the same drive, I find that 1.44 meg floppies can then be mounted and read correctly. Anybody else having similar problems? There is also a bug in the code of peekpoke.c and portio.c in lib/other. For instance, peek and poke (which must now open an I/O channel to /dev/mem to work in protected mode) share a flag (to indicate if /dev/mem is open) and the file handle for doing memory I/O. This saves some overhead by having the device opened just once on the first call to either peek or poke and it thereafter remains open. Only problem is that if peek opens /dev/mem, it uses O_RDONLY and if poke opens /dev/mem it uses O_WRONLY. The portio functions make exactly the same mistake with /dev/port. Does anyone see a problem with simple having both routines open the device with O_RDWR? BTW - the above bug prevents readclock from working in 1.5.0. I see no other program that is broken by it. Tim Bunnell <bunnell@henry.asel.udel.edu>
dlawyer@balboa.eng.uci.edu (David Lawyer) (01/04/90)
In article <7305@nigel.udel.EDU> bunnell@wizard.asel.udel.edu (Tim Bunnell) writes: >There is also a bug in the code of peekpoke.c and portio.c in lib/other. For >instance, peek and poke (which must now open an I/O channel to /dev/mem to >work in protected mode) ..... In addition to this bug there may be another problem: An old portio.c which is in assembly language and fails to use /dev/mem is in the lib/ibm directory. When I built libc.a this got included instead of the one in lib/other. I've now removed the old portio.c from the library. I'll bet that other people also have these duplicate names in their /lib since the many sibdirectories make this more likely. Dave Lawyer