September 2002 - Oberon - mailman3.inf.ethz.ch

Re (2): [Oberon] Reason for 'read pio error' ?
by muller＠inf.ethz.ch 02 Sep '02

02 Sep '02

Andreas Dörr <andreas.doerr(a)workingobjects.de> wrote: > Concerning the automatic remapping of bad sectors. My current theory is, > that the controller is only able to do this after a low level format marks > the bad sectors. Maybe someone could provide more definite information ... I also don't know, but would speculate that no low-level format is required. > Well I guess, almost all file systems suppose to operate on a perfect > media. I would not expect bad block handling from AosFS. Not really. I think this is a true oversight, although it is very rarely a problem. > Creating a file that contains all these bad blocks is the most > straightforward solution to the problem. From my point of view it has the > following drawback: Save access to a partition containing a bad sector file > is only possible on file level. Any tool accessing the partition on disk > block level will fail. Such a tool would have to do its own bad block handling. > Another solution would be to implement bad sector forwarding on the disk > driver level. This solution is transparent to all higher levels. It is even > possible to access the partition on block level. In BSD based Unix system > the command "bad144" does this. I'm not a big fan of this, since it hides the performance hit of the remapping. Urs Hölzle of Google told an interesting anecdote during a talk at the ETH. Google uses consumer hard disks for their servers, and one of the problems is that they do automatic bad-block mapping (in hardware). The disks keep working, but performance degrades significantly due to the additional seeks. Apparently they built some monitoring tools to detect bad (but working) disks for replacement. > For this solution a new common "BadBlock" error code needs to be introduced > to interface module "AosDisks". Otherwise a high level module like > "Partitions" would be bound to an error code coming from an implementation > of the interface module "AosDisks" (in this case "AosATADisk"). See below. > Since I own the "offending" disk, I will try to do this. Good! We need more volunteers willing to get their hands dirty with programming (and then afterwards stand back, look at what was done and clean up :-). > As a first step I > will implement a command which creates a file containing a given list of > bad blocks. If this is done, I will adapt the formatting code in > Partitions.Mod. Sounds like a good approach. > At first I will directly check for AosATADisk.Mod pio read > and pio write error codes. That's too specific, since a controller with bus mastering, or another driver, will give other error messages. I suspect it would be safer to treat any read error (on an in-range block) that is not a missing media or locking error, as a bad block error. If the error persists after a few tries, it is likely to persist after the next reboot also. > However, in the long run AosATADisk.Mod should > convert these error codes to a common error code defined in AosDisks.Mod. > Any idea, how the original error code could be preserved? > Controller.Transfer() only returns one result code. The strategy above seems simpler, instead of adding additional error return codes. If required, you could assign additional codes to global variables for debugging purposes, where they can be viewed with System.State. Or write messages with AosOut/Kernel.Write*. "Patrik Reali" <reali(a)acm.org> wrote: > In Aos, there is a command to > write one or more blocks to a file: you should try to write the offending > block and then the (separatedly) teh blocks are it. This could tell if only > one block or every block past that one has the same behaviour. I think Patrik means Partitions.ShowBlocks dev#part block [blocks] ~ "block" is the starting block to display in hex, and "blocks" is the number of blocks to display (Esc interrupts). See Partitions.Tool. Partitions.PartitionToFile and Partitions.FileToPartition could also be used. cheers -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] Reason for 'read pio error' ?
by muller＠inf.ethz.ch 02 Sep '02

02 Sep '02

Andreas Dörr <andreas.doerr(a)workingobjects.de> wrote: > I have successfully installed Bluebottle on a Dell Inspiron 7500. Good! > Currently I use a 5GB partition for Bluebottle. While trying to format a > second 5GB partition with AosFS I got an error '2820' at lba 12991229. A disk block is 512 bytes. So lba 12991229 translates to about 6.2GB (6.5GB metric). You didn't say what the disk size is, but I assume it is larger than this. Looking at AosATADisks.ReadPIO, it seems error 2820 is generated when the ERR bit is set after a command. At what stage does this error occur? I assume during Partitions.Format? > Does anyone know what is a typical reason for such an error? I'm not sure why the driver sees this ERR bit, and as you say, modern disks should remap bad sectors automatically. I'm not sure if they can do this without OS support. Perhaps the OS is required to retry a failed transfer? But then a second Partitions.Format should work... > The only workaround I currently know is to define a small partition that > includes the conspicuous block. This partition will not be used. Since the > number of partitions is limited this is not a very good workaround :-( Unfortunately this is currently the only workaround, since the AosFS file system does not handle bad blocks. What needs to be done is: 1. detect bad blocks in Partitions.Format 2. create a file that contains all these bad blocks This will ensure that the bad blocks are ignored by the file system. Part 2 is file system specific. If someone wants to attempt this, I suggest taking the relevant Format code from Partitions.Mod and rewriting it in a new module. Stefan Salewski <Salewski(a)physnet.uni-hamburg.de> wrote: > I think the 8GB-Limit still exist for Bluebottle and > ETH-Native-Oberon. This means Bios-calls are used to access the > harddisk, and this method is limited to the first 8 GB. I am > not sure if this is still true for newest Bios, but it was true > too for my /boot-partition of my Linux-Installation. This is only partially true. The boot file has to be below 8GB if you want to boot from the partition directly (otherwise you could use noboot.exe). This is another project for someone. Rewrite the OBL boot loader to support larger disks. The ATA and SCSI disk drivers and the AosFS file system support disks up to 128GB (the next hardware limit, surpassed in ATA-5, I think). > I cant imagine how you will fill 5 GB with Bluebottle. With data! cglur(a)onwe.co.za wrote: > ? number of partitions is limited ? > Is this the Microsoft limit of 4 ? No. You can have 4 primary partitions per hard disk (in the MBR), but an unlimited number of "logical drives" in an extended partition. BTW A new partition table format is slowly being introduced by Intel and Microsoft. It is not yet supported by Bluebottle. http://developer.intel.com/technology/efi/download.htm http://www.microsoft.com/hwdev/tech/storage/GPT_FAQ.asp Originally the motivation was to clean up their act for 64-bit Windows, but I suspect they'll want to switch to the new format for 32-bit Windows also, since the old MBR format is a mess. > Since Micro$hit's policy is to squash all other OS's, perhaps Please don't resort to childish name-calling, it is counter-productive. > For those who dare to step outside M$ limits with PC's, it's good > to be allied with linux. There are many soldier to clear the way for you. It is true that a lot of information can be gleaned from Linux. Sometimes you just have to dig quite deep for it. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

3 2

Re (4): [Oberon] Bug report: Character insert speed in Edit under 8.24 alpha NO
by pat＠picoworks.com 02 Sep '02

02 Sep '02

Pieter, You are correct, it looks to be a problem with memory transfer speeds with the implementation of VESA on the display controller I'm using. On the other had TextDocs spends far less time in Display but is far more consistent with adding characters in the middle of the texts due to it's different architecture. Solution, either use a supported display card or use TextDocs. For now I'll use TextDocs. Testing methodology follows: (KeyTest.Mod is included at the end of the message). Edit.Open "", place the caret in the resulting window and run Configuration.DoCommands StatProf.Start KeyTest.Do StatProf.Stop ~ Move the caret to the beginning of the third line and run Configuration.DoCommands again. In the first run with Edit it inserts 6721 characters and in the second only 92, quite a difference. Here's the results with Edit, Script and TextDocs Legend (all time in mS). (The timings varied from run to run but these are typical). characters, total, time in Displays, Get, Set (the last two get and set are SYSTEM.MOVE instructions in the procedure Displays.Transfer CASE op OF get and set... in the VESA display module) Edit 6721, 20135mS, 14142, 11696, 1715 92, 20038mS, 19904, 17219, 2616 Script 829 20020mS, 18600, 120, 17402 3501 200216mS, 13624, 6130, 4350 TextDocs 4902, 20010mS, 10525, 3146, 5260 3431, 20117mS, 11570, 3684, 4828 MODULE KeyTest; IMPORT Display, Oberon, Texts; VAR W: Texts.Writer; PROCEDURE Do*; VAR M: Oberon.InputMsg; t: LONGINT; ch: CHAR; i: LONGINT; BEGIN t := Oberon.Time(); i := 0; REPEAT M.F := NIL; M.id := Oberon.consume; M.fnt := Oberon.CurFnt; M.col := Oberon.CurCol; M.voff := Oberon.CurOff; IF (i MOD 70) = 0 THEN M.ch := 0DX ELSE M.ch := "a" END; Display.Broadcast(M); INC(i); UNTIL Oberon.Time() > t + 10000; Texts.WriteInt(W, i, 10); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); END Do; BEGIN Texts.OpenWriter(W); END KeyTest. KeyTest.Do System.Free KeyTest ~ Profiler.Profile KeyTest.Do ~ Configuration.DoCommands StatProf.Start KeyTest.Do StatProf.Stop ~

1 0

Re (2): [Oberon] Oberon FTP client
by peter_easthope＠gulfnet.sd64.bc.ca 01 Sep '02

01 Sep '02

pjm> In my experience the clients work well with the various Unix FTP servers we use at the ETH. I'm not aware of any Windows-based FTP servers here. Since at least 2 years ago the Oberon FTP client has also worked against NetPresenz running on MacOS 7.6.1. Regards, Peter E. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Homework on ZipTool (was Re: ZipTool1.Arc (Aug 5) can't handle DOS files ?)
by peter_easthope＠gulfnet.sd64.bc.ca 01 Sep '02

01 Sep '02

Pieter & others, pjm> Homework ... document the missing options and commands in Zip.Tool. Admittedly this is a mediocre job. For a thorough job I should have studied the sources but this is not a good opportunity. REVISIONS TO Zip.Tool OPEN ISSUES 1. Does the module always insist on the suffix "Zip" for archive names? I understand the rationale in creating an archive. What about for Directory and Extract? The syntax in the ZipTool could be a little more clear about the suffixes. 2. What exactly is meant by "level" and "strategy" in compression? This should be clarified in the ZipTool. 3. Given the syntax and capabilities of Add and Extract, is export of AddFile and ExtractFile justified? 4. An attempt to extract an entry with a name not consistent with the naming rules of the filesystem should produce an error message and then continue. 5. Logically, Add should follow Directory but in the module Add follows ExtractAll. ZipTool.Directory [\d | \D] Zipfile ~ ZipTool.Directory [\d | \D] ^ With option \d, details of entries of the specified zip-archive are shown and there is a style element for tabulation. \D is the same as \d except that there is no style element. ZipTool.Add [\level [\strategy]] ZipFile Entry1 [=> NewName1] Entry2 [=> NewName2] ... ~ ZipTool.Add [\level [\strategy]] ZipFile ^ ZipTool.Add [\level [\strategy]] ^ ^ level = "0" | "1" | "2" ... "9". strategy = "0" | "1" | "2". Option \level specifies the compression level. The default is -1. level = "0" for no compression. level = "9" for maximal compression. [More explanation needed.] Option \strategy specifies the compression strategy. [More explanation needed.] Example: ZipTool.Add \5 \2 Photos.Zip mountain.jpg tree.jpg ~ Note "Photos.Zip" rather than "Photos". ZipTool.Extract [\d] [\o] Zipfile.Zip file1 [=> NewName1] file2 [=> NewName2] ... ~ ZipTool.Extract [\d] [\o] Zipfile.Zip ^ ZipTool.Extract [\d] [\o] ^ file1 [=> NewName1] file2 [=> NewName2] ... ~ ZipTool.Extract [\d] [\o] ^ ^ With option \d, the file is stored in the directory according to the relative path in the file name of the entry. With option \o, files with the same name are overwritten. Otherwise they are renamed to filex.Bak ZipTool.ExtractAll [\d] [\o] [\p DstPrefix] ZipFile1.Zip ZipFile2.Zip ... ~ ZipTool.ExtractAll [\d] [\o] [\p DstPrefix] ^ With option \d, the file is stored in the directory according to the relative path in the file name of the entry. With option \o, files with the same name are overwritten. Otherwise they are renamed to filex.Bak. With option \p, DstPrefix is prefixed to all entries extracted. ZipTool.Delete Zipfile.Zip file1 file2 ... ~ ZipTool.Delete Zipfile.Zip ^ ZipTool.Delete ^ Specified entries are deleted from the archive. Peter Easthope http://carnot.pathology.ubc.ca/

1 0

Re: [Oberon] unknown EIP's in ETH Oberon
by muller＠inf.ethz.ch 01 Sep '02

01 Sep '02

Patrick.Hunziker(a)unibas.ch wrote: > SQLDrivers = Unknown EIP = 1F819C05H Unknown EIP means the EIP address could not be associated with any Oberon module and procedure. Normally the display would be something like: SQLDrivers = Module.Procedure PC = 1234 Is this a procedure variable pointing to an external C procedure or to an Oberon procedure? -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] Oberon FTP client
by muller＠inf.ethz.ch 01 Sep '02

01 Sep '02

Patrick.Hunziker(a)unibas.ch wrote: > Strangely, all Oberon clients (FTP.Mod, FTPDocs.Mod) available to me (Windows > Plugin Oberon 12/00 & 05/00, AosOberonSrc) work well if > I access an Aos FTP Server or a Unix FTP server, suggesting that they correctly > interpret RFCXXX. > However, they both fail when I try to access Microsoft FTP Server (IIS 4.0, IIS > 5.0). > Is this a known incompatibility, and how to get around it ? You do not mention how they fail. Do you get an error code when connecting, or is there a transfer problem? Try executing FTP.OpenLog before FTP.Open and see if any useful trace information is displayed. There have been problems with past versions of Oberon FTP clients, specifically with the last few bytes of a file being cut off. In the latest versions on Bluebottle and Native Oberon this is fixed. In my experience the clients work well with the various Unix FTP servers we use at the ETH. I'm not aware of any Windows-based FTP servers here. cheers -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

unknown EIP's in ETH Oberon
by Patrick.Hunziker＠unibas.ch 01 Sep '02

01 Sep '02

I am calling a windows dll ( ODBC32.dll ) from a Module ODBC (originally derived from V4). Loading the dll and its procedures appears to work, and the procedure variable address of some dll procedure is, according to "System.State ODBC": ... SQLDrivers = Unknown EIP = 1F819C05H ... What is the 'unknown EIP' when an address is found anyway ? It appears that the system has found ap procedure at the mentioned address. However, when I actually call ODBC.SQLDrivers, I get the error: ------------------ TRAP access violation in thread Oberon.Loop Unknown EIP = 77F821E1H EBP = 02EFF280H SQLBase.EnumDrivers PC = 3804 attribActLen = 0 attributes = "" cb = TestSQL.Enum PC = 254 cont = TRUE direction = 2 driver = "" driverActLen = 0 ret = 0 TestSQL.Do PC = 403 Interestingly, the unknown EIP and the procedure address, when added, give always 80000000H . Where does this mean, and how could this be remedied ? ---------------------- BTW: did anybody succeed in working with ODBC with ETH Oberon, and what are the hints to succeed ? Any most simple example code ? Greetings Patrick ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

1 0

Oberon FTP client
by Patrick.Hunziker＠unibas.ch 01 Sep '02

01 Sep '02

Strangely, all Oberon clients (FTP.Mod, FTPDocs.Mod) available to me (Windows Plugin Oberon 12/00 & 05/00, AosOberonSrc) work well if I access an Aos FTP Server or a Unix FTP server, suggesting that they correctly interpret RFCXXX. However, they both fail when I try to access Microsoft FTP Server (IIS 4.0, IIS 5.0). Is this a known incompatibility, and how to get around it ? Greetings Patrick ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

1 0

Re (3): [Oberon] Bug report: Character insert speed in Edit under 8.24 alpha NO
by muller＠inf.ethz.ch 01 Sep '02

01 Sep '02

pat(a)picoworks.com wrote: > I'm using the Vesa 2.0 driver at 1280x1024x16. This is a linear frame buffer driver, which means the whole display memory is mapped into the address space and all the raster operations are implemented in software. > This is on a 500MHz K6 with 256MB DRAM. Perhaps the problem is slow memory copying in the display driver. Anyway, the profiling should show what is going on. BTW For accurate profiling, you need a test that runs the relevant code for some time (more than 10 seconds). Both profilers (StatProf and Profiler) are sampling the current EIP at a rate of 1000Hz, so 10s will give you 10000 samples. StatProf was the first proof-of-concept implementation, and just gives the counts in a raw form, which you can use with Compiler.Compile *\f to find the actual code where time is spent. It works well to find inner loops where lots of time is spent. Profiler scans the call stack to find the active procedures on the stack and displays the nested structure of procedure calls. It is more coarse-grained, but gives a better overview of why certain procedures are called. It is useful if the inner loop consists of many smallish procedures (e.g. a compiler or protocol). -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0