cgs@umd5.umd.edu (Chris G. Sylvain) (09/29/90)
'scuse me -- who's got a working readclock on their pcAT?
Mine wouldn't even identify PC_AT properly until I cast the constant
CPU_TYPE_SEGMENT (== 0xFFFF) to 'unsigned'. Yes, I have /dev/port ..
MINIX crashes somewhere in port_out() when running in protected mode.
I looked over kernel/memory.c very carefully, and it seems just fine.
I'm stumped. Who's got an idea where to go from here?
PS: not all the lseek()s in portio and peekpoke use SEEK_SET, some still
use a bare '0' as a parameter. For that matter, sometimes the
read() or write() count parameter isn't (size_t), but is (unsigned)
instead. In other words, it's sorta ANSI-fied, but not consistently.
--
--==---==---==--
Toves: Animals something like badgers, lizards, and corkscrews
-- ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 --
-- UUCP: ..!uunet!umd5.umd.edu!cgs --cgs@umd5.umd.edu (Chris G. Sylvain) (10/02/90)
I had created /dev/port when I began looking into why readclock was always
returning '-q' .. I took a wrong turn when I found peek() reported the
correct id byte (0xFC) when I cast CPU_TYPE_SEGMENT to (unsigned) ..
The real answer was: /dev/port is created by 'mknod port c 1 4'
(a _character_ special device) NOT by 'mknod port b 1 4' (a _block_ special
device). Then make readclock Set-UID of the owner of /dev/port ('bin' for me).
No cast of CPU_TYPE_SEGMENT is then necessary ..
I note no cdiff against the file system prototype file supplied with
v1.2 MINIX (and not changed for v1.3) was included in the v1.5.10 upgrade kit.
Also, no mention of the special case for /dev/port being a character special
instead of a block special device is made in kernel/memory.c .. Clues and
hints are always appreciated when they do appear !!
--
--==---==---==--
Wabe: It goes a long way beyond a sundial on either side
-- ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 --
-- UUCP: ..!uunet!umd5.umd.edu!cgs --evans@syd.dit.CSIRO.AU (Bruce.Evans) (10/07/90)
>MINIX crashes somewhere in port_out() when running in protected mode. Readclock should do a stat on /dev/port and complain and not proceed when /dev/port is a block device. >PS: not all the lseek()s in portio and peekpoke use SEEK_SET, some still > use a bare '0' as a parameter. For that matter, sometimes the > read() or write() count parameter isn't (size_t), but is (unsigned) I fixed this and another bug in version 1.x.y (x = 4 or 5) but the fix got overwritten by another version of the fix for the other bug in version 1.x.(y+1). Everyone was too tired for another round of trivial fixes. -- Bruce Evans evans@syd.dit.csiro.au
greg@suntan.viewlogic.com (Gregory Larkin) (04/04/91)
Hi, I am trying to compile "readclock" under V1.5-PC. I get the following messages: portio.s, 14: expr syntax err portio.s, 64: expr syntax err portio.s, 65: expr syntax err portio.s, 70: expr syntax err portio.s, 71: expr syntax err exit.s, 11: I0013 multiple declared isatty.s, 22: I0013 multiple declared lseek.s, 32: I0013 multiple declared open.s, 31: I0013 multiple declared unresolved references: .c .s Does anyone know what this means? BTW, I have the standard 1.5 distribution with estdio2.1 installed. Thanks, -- Greg Larkin (ASIC Engineer)|"This is a fragile ball we are living on; Viewlogic Systems, Inc. |it's a miracle and we are destroying it.." 293 Boston Post Road West |Peter Garrett, Midnight Oil Marlboro, MA 01752 (greg@Viewlogic.COM)
greg@suntan.viewlogic.com (Gregory Larkin) (05/24/91)
Hi there, Does anyone know why readclock(1) is the only executable in the 1.5 distribution that will no longer recompile now that I have installed the Estdio library? I have to still use the V1.3 readclock(1). Also, it always prompts me for the date. This machine is a true IBM-AT, shouldn't readclock(1) find the internal clock and use it? Would this be affected if the battery has to be replaced? I get this from asld when linking readclock(1): portio.s, 14: expr syntax err . . . exit.s, 11: I0013 multiple declared . . unresolved references: .c .s Looks pretty weird.. Does anyone know what it means? Thanks, -- Greg Larkin (ASIC Engineer)|"This is a fragile ball we are living on; Viewlogic Systems, Inc. |it's a miracle and we are destroying it.." 293 Boston Post Road West |Peter Garrett, Midnight Oil Marlboro, MA 01752 (greg@Viewlogic.COM)