On Tue, 31 Dec 1996, Amit Gupta wrote:

> In order to complete it (and assuming people think it's worth going
> ahead), I need some input from folks here. Mark and Rob could answer all
> of these questions but I suspect they might be too busy : 
Yep.
 
> 1) An up-to-date list of available sets together with 1-line description
> and uncompressed size. Does anyone fancy doing this, please ? Not having
> my own installation yet I cannot work out the uncompressed size without a
> lot of hassle. 

Erm this needs doing. My only suggestion would be to look at all the .set 
files in the 1.2-release and 1.2-contrib directories.
 
> 3) Does povray run correctly yet ? I recall that it used to coredump. 

Not last time a checked. However I need to retest this given some recent 
changes I have made but not yet commited as they are still undergoing 
testing.
 
> 4) Does someone fancy doing some timing tests on the FP performance under
> StrongARM ? The question on FP performance really ought to have a MFLOPS
> figure to quantify it.

What would be useful would be to have a source tar file of a load of 
benchmarks and a script to run everything. The byte benchmarks look quite 
good so perhaps these coupled with dhrystones, whetstones and mflops 
would do.
 
> 5) How big (in Mb) is a GENERIC kernel these days ? 

Recently 1.7MB but the 400K increase was due to a load of local symbols 
not being stripped. New kernels will be around 1.3MB-1.4MB

> 6) I suspect that the list of kernel-related bugs in RiscBSD is now well,
> well out of date. We need an up-to-date list of known kernel bugs. Does
> anyone know of any and, if so, can you tell me ? I suspect only Mark has
> the definitive list. 

Well I suspect that my list may not contain everything atm. It will 
certain contain a lot of things that users do not consider bugs or have 
not observed.
The 4 main nasties in the kernel are:

1. inode trashing (there is a patch to fix this but not cure it)
2. lpt driver panics the kernel on some configurations
3. console code is bugged
4. sfas216 scsi drivers have problems with interrupts and multiple devices.

Of these

1. Cause unknown, on my todo list. The patch fixes up the trash after it 
has occurred.
2. Cause unknown, I cannot generate this so have not yet traced it. 
Several of the changes made over xmas may help.
3. Being re-written as we speak.
4. Possible disconnection/reconnection problems waiting for me to take a 
look.

> 7) Is there any 16-bit sound support yet - either a simple beep or full
> audio ?

The beep waveform can be adjusted for 16bit so you get a proper beep on 
16-bit sound cards.
The audio system needs looking at and overhaulling.

> 8) Any chance of an up-to-date list of supported SCSI and Ethernet cards,
> together with the status of their drivers (alpha, beta, polling,
> interrupt-driven...) ? People have mentioned e.g. VTi cards and problems
> with various Ethernet cards - can you tell me, please ? Something
> involving an ehbug parameter seems to come up occasionally which really
> ought to be in the FAQ - can someone explain it, please ? 

SCSI cards
asc	Acorn SCSI 1	- working, interrupts, no DMA - card DMA planned (mark)
cosc	Connect32	- working, no ints, no DMA - work planned (mark)
ptsc	Powertec	- working, no ints, no DMA, work planned (mark/scott)
csc	Cumana SCSI 2	- working, no ints, no DMA, work planned (mark/scott)
oak	Oak SCSI 1	- alpha, no ints, no DMA - no work planned
???	Cumana SCSI 1	- work pending (mark)

IDE cards
???	ICS IDE		- alpha, merge into the source tree soon (mark)
???	Yellowstone	- No card, No info, NO WORK

Ethernet cards
ea	ANT ether3/5		- working
ea	Atomwide ether3/5	- working
eb	ANT network slot	- working
ie	Acorn ether 1		- beta but seems to work
eh	Icubed etherH		- alpha bugged. New driver being written by
				  mark

The ehbug option is a work around for a bug that exists on some etherH 
card chip sets. With some cards the ethernet controller locks the bus if you
try and xfer more than 128 bytes in one go. Under normal operations this 
is not a problem but the card RAM test can trigger the lock up. So if the 
kernel hangs when attaching the driver for the etherH driver try adding
the option ehbug to the other options field in the boot loader.
This will go away when I complete the new etherH driver.

> 9) What's the current take on Hydra support ? What works and what dosen't
> ? I suspect the kernel team will have to answer this. 

I am working on support. I can target specfic code to specific processors.
Full support will take longer and will probably be linked with MI work on 
multiprocessor NetBSD. Folks with hydras who want to use them should 
contact me directly.
 
> 10) Does MudOS compile successfully under gcc 2.7.2.1 ? Has anyone tried ? 

Dunno. The latest compiler release has several patches from the GCC/arm 
maintainer on top of 2.7.2.1 and these fix a number of compile problems.
If there is still a problem let us know.

> 11) The list of X bugs is also probably out-of-date; for example, it
> claims that Xarm-mono dosen't work with most kernels. Any chance of an
> up-to-date list, please ? At the very least, maybe someone can try out the
> current bug-list and see whether any of them have been fixed ? 
This is one for Rob. The latest X server is a LOT more stable than 
previous versions.

Cheers,
				Mark

Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716