crew@pitt.UUCP (Al Crew) (02/03/89)
I have been working with ast to test his latest changes to the kernel
to support the PS/2.
Test results:
1) I do not think your patch (ps=1) is needed:
The Model 30-286 should not have ps=1 (it is an AT in PS/2 clothes).
The Model 50&60 are PS/2 and ps is correctly set.
2) Specific results:
Patched Unpatched
(ps=1)
Model 30-286 no kb works
Model 50 works works
Model 60 works works
Model 70 crash crash
Model 80 crash crash
With the patched version, the Model 30-286 does not recieve
keyboard input. The menu comes, but any input is ignored.
On the Model 70 and Model 80, both version crash after
the "=" is entered, but before the screen is cleared
"Works" means all of the V1.3 test programs ran.
PS What is Steve Ackerman's mail address?crew@pitt.UUCP (Al Crew) (02/03/89)
ast has requested that I run some heaver tests on the Model 50 & 60. I will do this and report the results. I am also going to change the cpu model detection logic to set the ps_at flag for the Model 70 and 80. I grep'ed the kernel code to see where the ps_at flag is used. I think it should be set for the Model 70 and 80.
crew@pitt.UUCP (Al Crew) (02/04/89)
>ast has requested that I run some heaver tests on the Model 50 & 60. >I will do this and report the results. Bad news. I ran the V1.3 'tests' from a floppy with a 'dd' command reading blocks from the hard disk. It would run for about five minutes and then hang with the floppy's select light on. "F1" would show that a task was waiting on FS and FS that was waiting on FLOPPY. > I am also going to change > the cpu model detection logic to set the ps_at flag for the Model 70 and 80. > I grep'ed the kernel code to see where the ps_at flag is used. > I think it should be set for the Model 70 and 80. Didn't seem to help. To Steve Ackerman: I am using bios_wini and it seems to work. (I am able to use dd and dosdir to access the hard disk. The model 50 is not mine, so I can not create a Minix partition.) Steve, you have a model 80, don't you? If so, I assume you are running the code you modified, not the code ast modified. (Since I can't get ast's code to run on a model 80.) Try setting ps_at. Without that flag, Minix uses the XT wini interrupt instead of the proper one. Al
ackerman@uvm-gen.uvm.edu (Steve Ackerman) (02/05/89)
In article <4539@pitt.UUCP> crew@pitt.UUCP (Al Crew) writes: > > Bad news. I ran the V1.3 'tests' from a floppy with a 'dd' command > reading blocks from the hard disk. It would run for about five minutes > and then hang with the floppy's select light on. "F1" would show that > a task was waiting on FS and FS that was waiting on FLOPPY. > What code are you using? Earlier, you posted the results of your test in which the 50 and 60 worked both with PS=1 or PS=0. Is this with Dr. Tanenbaum's code, and unmodified? I've sent you a copy of main.c, proc.c, and floppy.c. Floppy.c implements parts of Gary Craig's changes. Could you please test them? > I am using bios_wini and it seems to work. (I am able to use dd and > dosdir to access the hard disk. The model 50 is not mine, so I can > not create a Minix partition.) Steve, you have a model 80, don't you? > If so, > I assume you are running the code you modified, not the code ast modified. > (Since I can't get ast's code to run on a model 80.) > Try setting ps_at. Without that flag, Minix uses the XT wini interrupt > instead of the proper one. Thanks. That was the problem. Last night, I patched Dr. Tanenbaum's code (plus some changes) so that PS=FALSE, PC_AT=TRUE, and MCA=TRUE (variable I added). Bios_wini worked! And then, in my excitement, I accidently wiped out my dos partition. Since I was using a DOS program to transfer between 5 1/4 and 3 1/2 inch disks, I wasn't able to copy the 1.3 test programs. When I rebuild my Dos partition, I'll run them and post the results. As far as the best coding solution, I like Bruce Evan's suggestion of masking out the interrupts in mpx88.s. Then, most of the machine dependent code (at least for interrupts) could be kept to one file. -- ============================================================================ Steven Ackerman | EMBA-CF University of Vermont uunet!uvm-gen!ackerman | Burlington, Vermont 05401 Internet: ackerman@uvm-gen.uvm.edu | Telephone: (802) 879-0371
crew@pitt.UUCP (Al Crew) (02/06/89)
In article <1054@uvm-gen.UUCP> ackerman@uvm-gen.uvm.edu (Steve Ackerman) writes: >In article <4539@pitt.UUCP> crew@pitt.UUCP (Al Crew) writes: >> Bad news. I ran the V1.3 'tests' from a floppy with a 'dd' command >> reading blocks from the hard disk. It would run for about five minutes >> and then hang with the floppy's select light on. "F1" would show that >> a task was waiting on FS and FS that was waiting on FLOPPY. >> > What code are you using? Earlier, you posted the results >of your test in which the 50 and 60 worked both with PS=1 or PS=0. >Is this with Dr. Tanenbaum's code, and unmodified? I've sent you >a copy of main.c, proc.c, and floppy.c. Floppy.c implements parts >of Gary Craig's changes. Could you please test them? Sorry for the misunderstanding. I am using Dr. Tanenbaum's code, unmodified. Although I didn't explicitly check it with a printf, I believe it sets ps=1 for both the Model 50 & 60. Dr. Tanenbaum told me to add a line explicitly setting ps=1. The code worked both with and without that line. I believe that in both cases, ps was set to one. Is that more clear? >When I rebuild my Dos >partition, I'll run them and post the results. Please try the test I used, dd running in the background reading the hardisk and the V1.3 tests running from floppy in the foreground.
stevel@eleazar.dartmouth.edu (Steve Ligett) (02/07/89)
Ok, there are two methods of handling PS/2 interrupts that I know work: 1. Silence in dividual devices, 2. Mask interrupts in the 8259, a third, sounds good, but I don't recall if anyone has it working: 3. Delay sending EOIs till the interrupt is handled in the device task. Some thoughts I've had. #1 was the most obvious to me, and is easy for all devices that I know about except the floppy disk. IBM has added registers and bits to make it easier than it was (in PCs) for some devices, but has done away with the bit (in the DOR) that made it easy for floppies. In general this method means writing a bit to a register (perhaps reading the reg first and or-ing in the bit). #2 works, but seems like using a sledge hammer to me. #3 sounds the best to me now, and I wish I'd thought of it. For methods 2 and 3 to work well, I think we have to look at setting the 8259 into Special Mask Mode (SSM). Normally, acknowledging an interrupt or masking an interrupt means that all lower level interrupts are masked as well. In SSM, just the level being serviced or masked in inhibited; lower level interrupts are allowed. This would let serial interrupts be recognized when clock, hard disk, or keyboard interrupts are still being handled. (I've just gotten minix 1.2 going on my PC, and am now ready to try to help with 1.3, rather than just provide ideas based on reading databooks.) Steve Ligett steve.ligett@dartmouth.edu or (decvax harvard linus true)!dartvax!steve.ligett
ast@cs.vu.nl (Andy Tanenbaum) (02/08/89)
In article <12117@dartvax.Dartmouth.EDU> stevel@eleazar.dartmouth.edu (Steve Ligett) writes: >Ok, there are [3] methods of handling PS/2 interrupts that I know work: > >1. Silence individual devices, >2. Mask interrupts in the 8259, >3. Delay sending EOIs till the interrupt is handled in the device task. I tend to favor #2 or #3 because I don't know how to silence the Ethernet card. With some effort, I can probably think of many more devices I don't know how to silence. >For methods 2 and 3 to work well, I think we have to look at setting the >8259 into Special Mask Mode (SSM). Normally, acknowledging an interrupt >or masking an interrupt means that all lower level interrupts are masked >as well. In SSM, just the level being serviced or masked in inhibited; I am nervous about this. The bios_wini.c seems to work almost everywhere, so I'd like to make this part of the standard boot diskette. That way it could boot on any machine. People could then compile and install xx_wini.c is they wanted to get the extra performance. If we change the 8259A mode, the BIOS may get all confused. Furthermore, they may be other devices that don't like messing around with the 8259A. That is a very central chip to the whole I/O system, so I am hesitant to reprogram it until I fully understand the repercussions of doing so. Still, if anyone wants to try it and report back what happens, that could be a start. One thing that still confuses me is why Al Crew (and now David Dyck) report being able to boot my kernel on the PS/2 Model 50. What my kernel does is disable floppy interrupts in mpx88.s by twiddling bits in the 8259A. In interrupt(), I changed the code to if (task != FLOPPY) port_enable(INT_CTL, ENABLE) /* re-enable 8259A */ In floppy.c, I re-enable the 8259A floppy bit after sensing the FDC. In effect this is solutions 2 and 3 above. However, it is only for the floppy! Everything else works the way it always did. Why don't we get infinite clock interrupts etc? Is the floppy the only level-triggered device? Do the other devices negate their levels automatically? Strange. Andy Tanenbaum (ast@cs.vu.nl)