Custom Query (69 matches)

File "ifslog.c", routine "trace":

you need to remove this block of code, otherwise invocation of "message" function will still not correctly deal with the trace flags:

294	static BOOL fInitted = FALSE;
295	static BOOL fTraceEnabled;
...
306	   if (! fInitted)
307	      {
308	      // check if tracing with TRACE_MAJOR is enabled
309	      fTraceEnabled = pGI->amecRAS[TRACE_MAJOR / 8] & (0x80 >> (TRACE_MAJOR % 8));
310	      }
311	   fInitted = TRUE;
312	
313	   if (! fTraceEnabled)
314	      return 0;

I don't know if you still need routine "Trace" (written with capital T).
Of course that will then miss the check for the trace flag. It would be best to get rid of it and use routines "Message"/"message" instead.

SVN rev 325 just completely blocks the WPS on system start. Everything, including my USB mouse becomes unresponsive and I have to reset the system with the reset switch.

SVN rev 322 does not exhibit this problem.

Using SVN rev 315:

1) added the /FAT switch to FAT32.IFS. The original intention was to be able to use a FAT16 partition > 2 GB as a dump partition (and therefore to get rid of UDUMPFS.IFS which by the way works fine just as you described in FAT32.IFS)
2) attached a USB floppy drive, inserted a floppy and attempted a read (via WPS)

The result was that it took for ages for the contents to show up. Accessing a file of only 20 bytes took for ages even though the actual floppy read was very short (the drive just kept spinning for a very long time without any apparent activity).

Removing the /FAT switch and therefore using the kernel builtin FAT12/FAT16 support fixed the problem, that is, it worked and works with a speed that can be expected from a floppy drive.

Would there be a chance to exclude FAT12 media from support by FAT32.IFS or at least make this configurable via a switch ?